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ABSTRACT 


In 1972 the Chief of Naval Material perceived a 
proliferation of small computer types in the Navy 
inventory. To stem that proliferation a standard 
minicomputer was procured, to be used in all current 


and future tactical systems requiring a small digital 


processor. That standard was designated the 
AN /UY K-20 (V) Data Processing System. Lack of 
dedicated appropriated funds for procurement and 


Support forced the Chief of Naval Material to tax the 
users of the systen to obtain the necessary 
development and operational Support funds. Premature 
delivery of the system to meet user schedules resulted 
in highly unreliable equipment being used in 
development efforts. A significant adverse impact on 
user project costs and schedules resulted. 
EXamination of the standard minicomputer acquisition 
fosters a number of recommendations for future 


tactical digital processor acquisitions. 


OX t BRA RY 


%, CALIFORNIA ” Sega 





TABLE OF CONTENTS 


» 


BEEMINSE (01 Gste'olclsts so ses cle isis ale «so sete) 6s) 02.6 016s 6 0 6 6 6 ees ee se 6 5 0 6 06 8 
emer SIEM #1) (3 15 11 Ly Nile os) elolelat siecle 6 es 6 0 0 6 6 6 6s 6 0s seo vc 066s eee s 4s 11 
PION LE OU GMO Niebetelcrsie eisis! 6156) e(eleisiei oleic ssc eeceeceaecece U2 

Ages Etro Sm Omit y cls cielledeve cisiterciele) +o. « 6.460 0 66 616 6 «6 12 

toe ee yee) Oly CG re wetersiereleis'e\6 elelel ele eso 4 9 «0 ees eee osc <6 13 

II. IDENTIFICATION OF THE NEED FOR A STANDARD 
OMT ER oso 4c ccs cles e ce te ck Ce hee eee wees ces ce 14 
Dae Gree Nia CO OF AMEN TCOMPUTE RR... «ccees 6s ces os 16 

B. DEFINITION AND IMPLICATIONS OF A "STANDARD"... 17 

Coe Lobe aniGk OF CAPABDTLEEPEES NEEDED... << «cs alee ecu 

nome UG ICCRCIMIAINicrei's io ne otene..6, el(sielies 1c 4 6) oJ60s o\ene,0.0'-enetele.cemeneel 

Pee keldapliagtyrand*haintainabi lity... .ss.< secs 

BG TCCLINICE .. os shite cs se eis oe 0. We 0 bieleielaiece os) see 

4. EMPUtE/OUC NUE. 22. nc ees cece ees wens Sree is) ce SCS 

Siok SL Wntic ies tSicvaueie.0 6 0 otehaisie vise 06.0 0 isos sists ecoreteremneall 

6. GOntErol/Malntenance Panel oo. . 66060 cle ce uc) CE 

l -EIOMEM MANN Cite onsl eiedels s-ololleivieislc «6 orels © 01s celeiens/s.s/ cite neae 

D. CAPABILITIES OF EXISTING NAVY COMPUTERS TO MEET 

Ser PC AL UO S cic ow cc se sce wc ee ss sees es tees es tee + 6 eS 
Ui etMRON teetCLN Elicrowe, ioleiieiiei'e ie <e ‘alta eelie 14.0) 0/8 uals keke ace emenewenene 30 

ZAG mo Vi) aves 6 a ores) sie a aac oeee ee a clevareie sie MOU 

ES ool =O) 9) (Olea ohcteMicie usin sire ists iaifciels atersie «ics secs) eheioteiie moe 

ANA Wee) aigheneomsts crscarcials oe octets <-eharetece ee 

mer. DEVELOPMENT AND PRODUCTION HISTORY...c.ccceoce sie sie co) 
Prev RCOALTON OF “THE SYSTEM ccs cee ce cee ce este was ce OU 
Ae COMPARISON OF SPECIFICATION AND FINAL 
PRODUCT eee eecteteieieiisl ellsivicl sie ielale ele oieteiciots: aleietelsie ce ete moO 
Bie COMPARISON OF AN/UYK-20 DPS WITH THE 1972 
Meriter SoHhtbe EN ECOMPULER STATE-OF-THE-ART......00¢ es 57 
PPR SRCHIb GC Crolli © <li sis ¢is\o1 clei ei snoleusis «© v6 6 stele o eheltsie a7 


Ce AMINT CI OMAY of evens. civl¢ s isle 4.0 6160 ws so 0s d.0 cre-eeeves.” O00 

SPE HSIUE NGIEOM NOC Cis. ssc cle ec cselesecacinnce as 61 

DE PU OMG Us loiclaislc csc c0ecececcesccsecsecsea O83 

Set CREP te otUIGl Ul OCmMEdais soc ese ccc se cesses | OF 

CEMCO MoU GeeNOss calecs s aiclcclee sos cseseec ce esse OU 

eer es Oiler ONGe Wi C's iss ace «sis oc ole sees ee esess cos O06 

=> IMPACT OF AN/UYK-20 DPS ON DEVELOPMENT OF USER 

SPT Me Uciclc!slctelciclslcl< eisisicdulecicllels ec ce ce os ce sec ce enseeecececes OF 
1. Establishment of AN/UYK-20 as a Standard. 68 

26 Hardware/Firmware Capabilities, .26gi.6 060 30 

Seva wap Lilcy Of SUPPOLt SOftWare....ee6. 973 
eweOUDDOLtESOft Ware CapabilltleS...«<<escesueces 16 

SreeA Val tdbmiiey OF PEripheralS. «oc. cece ceuun Lu 

6. Hardware and Software Reliability and 

BME IMADLLALY. 0. ccc ccc c es ee se sncscccsscsecesescescess 78 
os Lack of Dedicated Appropriated Funds to 

Pemeomes the AN/UYK-20 DPS.s. secs sccnccsesesccssecsccssse § 80 
Ve. SUMMARY, CONCLUSIONS AND RECOMMENDATIONS......2-- 82 
megeuaax As AN/OYK-7 SYSTEM DESCRIPTION... ccccsccsecess 88 
Appendix B; SLANDARD AMEN TCOMPUTER SPECIFICATIONS. .... eee 
Appendix C: CP-642B SYSTEM DESCRIPTION... .cceecccccccee 92 
Appendix D: AN/UYK-15(V) SYSTEM DESCRIPTION..........-. 94 
mopenarxe EF: CP-890 SYSTEM DESCRIPTION. .ccccsccceesesece 96 
memendax F: AN/UYK-12(V) SYSTEM DESCRIPTION. ..ccsecvsese 98 
Appendix G: DESCRIPTION OF SYSTEM SOFTWARE.....eeeeeee- 100 
meoemarx Hs: AN/UYK~20(V¥) DPS DESCRIPTION. .cccccsecscesse 105 
Appendix I: BASIC AN/UYK-20 HARDWARE CONFIGURATION AND 
IE MICE Mote oi el eres: es are aiene ee: aire. o7 elo W0ie) oo 6s: o 8 $6. 84,0 6 0 0 e's ae) svevevenee Ot, 
Pemenary J: ROEM 1602 SYSTEM DESCRIPTION. ..cccccceceses 109 
Appendix K: HP2100A SYSTEM DESCRIPTION... .cccccccccccee 111 


Appendix L: DEC PDP-11/45 SYSTEM DESCRIPTION..... wns chee 
Appendix M: VARIAN-73 SYSTEM DESCRIPTION......... see are eS 
MOO REFERENCES ....< 0 «tvs cece sccscccccccccceccscesces 417 
MMO DISTRIBUTION LIST... oc cccsccveccevcesccecceucse . 119 


mor OF RCGMUBINOIS ieaWa vera occ wets 'so) oo0) “ovouene eelece Wee. 6 6 elec e 0 eoelale os «sexe 7 





LIST OF FIGURES 


fee Naval Material Command OrganiZation...cccccccccces 2. t35 
wean 7 UYK= 20 (V) SyStem USCIS. . cc cc cece ccc ccc cece cccccee 34 


3. Naval Electronic Systems Command Organization....... 53 





GLOSSARY 


AADC - All Applications Digital Computer 

ADD - Alphanumeric Display Device 

ADP - Automatic Data Processing 

APE - Advanced Production Engineering Model - a militarized 
prototype 

CDC - Control Data Corporation 

CMTU - Cartridge Magnetic Tape Unit 

CNM - Chief of Naval Material 

CNO - Chief of Naval Operations 

COMNAVELEX - Commander, Naval Electronic Systems Command 

CVTSC - Carrier Tactical Systems Center 

DCAS - Defense Contract Administration Service 

DEC - Digital Equipment Corporation 

DMA ~- Direct Memory Access 

DPS - Data Processing System 

DRG - Design Review Group 

ESA - Externally Specified Addressing 

FCDSSA - Fleet Combat Direction Systems Software Activity 

FDM - Functional Demonstration Model - a non-militarized 
prototype 

GFCS - Gun Fire Control System 

GFE - Government Furnished Equipment 

IBM ~' International BuSiness Machines Corporation 

ILS - Integrated Logistics Support 

oO) => input/Output 

IOC - Input/Output Controller 

ISADC - Interim Standard Airborne Digital Computer 

LSI - Large Scale Integration 

MATHPAC ~- Plug-in module of floating-point, trigonometric 


and hyperbolic functions implemented in microcode 





MICROGROWTH - Plug-in module of user specified microprograms 
MOS - Metal Oxide Semiconductor 

MSI - Medium Scale Integration 

MTBF - Mean Time Between Failures 

MTTR - Mean Time To Repair 

NAFI - Naval Avionics Facility, Indianapolis 

NAVAIR - Naval Air Systems Command 

NAVELEX ~- Naval Electronic Systems Command 

NAVMACS - Naval Message Address Communications System 

NAVMAT - Naval Material command 


NAVORD - Naval Ordnance Systems Command - combined with 
NAVSHIPS to form NAVSEA 

NAVSEA - Naval Sea Systems Command - formed by combining 
NAVORD and NAVSHIPS 

NAVSEC - Naval Systems Engineering Center 

NAVSHIPS - Naval Ships Systems Command - combined with 


NAVORD to form NAVSEA 

NELC ~- Naval Electronics Laboratory Center 

NESEC - Naval Electronic Systems Engineering Center 

NTDS - Naval Tactical Data System 

OMB - Office of Management and Budget 

O&MN - Operations and Maintenance Navy Appropriation 

OPEVAL - Operational Evaluation 

OSD - Office of the Secretary of Defense 

QA - Quality Assurance 

RAM - Random Access Memory 

RDT&EN - Research, Development, Test and Evaluation Navy 
Appropriation 

REWSON ~- Reconnaissance Electronic Warfare Systems Office 
Navy 

RFP - Reguest for Proposals 

ROM - Read-Only-Memory 

SECDEF - Secretary of Defense 

SSA - Source Selection Authority 

SSAC - Source Selection Advisory Council 


SSEB - Source Selection Evaluation Board 








PASO - Tactical Daca ead Systems Office of the Naval 
Material Command 

TADSTAND ~ Tactical Digital Standard 

TALOS - long-range, surface-to-air missile 

TARTAR - short-range, surface-to-air nissile 

TECHEVAL - Technical Evaluation 

TERRIER - intermediate-range, surface-to-air missile 

TTL - Transistor-Transistor Logic 

UNIVAC - UNIVAC Defense Systems Division of Sperry-Rand 
Corporation 

WCS - Writable Control Store 


10 





ACKNOWLEDGEMENT 


i wish to thank the many personnei of Navy activities 
and private contractor firms who took time out from their 
busy schedules to answer my guestions. Thanks also to ay 
two thesis advisors, Professor Stephen Jauregui and LCDR 
Edward Zabrycki, who waited patiently for the thesis to 
emerge from my research. Finally, special thanks go to the 
Commander, Naval Electronic Systems Command (PME~-107) who 
provided funds to make this thesis possible and to ny wife, 
Ann, who relieved me of many family obligations during the 


final crunch. 


11 





A. THESIS OBJECTIVE 


In 1972 the Navy began procurement of a small digital 
computer which was to be a standard minicomputer for 
tactical system applications. That standard minicomputer 
was later designated the AN/UYK-20(V) Data Processing 
System. 


The acquisition strategy employed and the resulting 
events of the first three years of production caused great 
concern among project managers who were required to use the 


standard minicomputer. 


At least one user project manager believed that an 
objective look at the standard minicomputer acquisition was 
necessary to prevent recurrence of those events which 


adversely impacted on the development of tactical systems. 


It is the objective of this thesis to examine the 
Standard minicomputer acquisition process, to evaluate the 
system in light of user needs and 1972 state-of-the-art, to 
identify those events which contributed to the adverse 
impact of the standard minicomputer on development efforts, 
and to offer some recommendations for future acquisitions of 


Standard tactical digital processors. 


Be. METHODOLOGY 
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In order to obtain information about minicomputers in 
general and the AN/UYK-20(V) Data Processing System in 
particular, a literature search was conducted. Pertinent 


references are listed at the end of the thesis. 


To obtain a complete and objective picture of the 
acquisition process it was then necessary to contact 
personnel at all levels in user project organizations and 
also personnel in the standard minicomputer project 
organization. The following types of activities were 


contacted to obtain information: 


* Navy field activities - responsible for assembly, 
checkout, delivery and maintenance of tactical 


systems hardware and software. 


* Navy laboratories - responsible for certain aspects 


of tactical system development and testing. 


* Private contractors - responsible for hardware and 
software development of tactical systems under 


contract to Navy project offices. 


* Navy project offices - responsible for management of 
the acquisition of tactical systems utilizing UYK-20 


as a system component. 
Additional information was obtained by attending two 


AN/UYK-20 User's Group meetings. A minimal amount of 


laboratory experience was gained on the UYK-20 itseif. 
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The 1960's saw the first successful employment of a 
general purpose digital computer ina shipboard tactical 
system. This event precipitated the introduction of a large 
number of shipboard computers into the Navy inventory 
manufactured by several different companies with slightly 


different capabilities. Some of these computers are ‘listed 


below. Others existed, particularly in avionics 
applications. 
Computer Sysco Application 
MK 74 NAVORD TARTAR Missile System 
MK 76 NAVORD TERRIER Missile Systen 
MK 77 NAVORD TALOS Missile Systen 
MK 86 NAVORD Gun Fire Control Systen 
AN/USQ-17 NAVSEC NTDS 
AN/USQ-20 NAVSEC NTDS 
CP642 NAVSEC NTDS 
CP642A NAVSEC NTODS 
CP642B NAVSEC NTDS 
AN/UYK-~-7 NAVSEC NTDS 
AN/SYA-12 NAFI Communications 
AN/UYK-15 (V) NAVSEC General Purpose 
CP890 NAVSHIPS Navigation 
AN/UYK-12 (V) NAVSHIPS General Purpose 


This proliferation of tactical processors created the 


following tyres of problems: 


* Small and uneconomical procurement programs. 
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* Untenable material and logistics support posture. 

* Increased scope of personnel training requirements. 
* System interface and integration problems. 

* Software incompatibility. 


* Proliferation of support software. 


Recognition of these problems prompted the Chief of 
Naval Operations (CNO) to direct the Chief of Naval Material 
(CNM) to develop a standard general purpose computer for 
shipboard and shore applications. In August 1971, CNM 
created the Tactical Digital Systems Office (TADSO) 
(MAT-O9Y) to carryout this directive. Figure 1 shows the 
position of fTADSO in the NAVMAT organization as of January 
1975. The chart illustrates that the Director of TADSO was 
in an influential postition, reporting directly to the Vice 
Chief of Naval Material. MAT-O9Y has traditionally been a 
Rear Admiral. 

CNM, by reference 1, described the scope of fTADSO 
efforts: 

"(1) %Inter-and intra- platform compatibility of ail 
tactical digital systems and equipment. 

(2) Standardization of tactical digital equipment and 
associated software. 

(3) Configuration and interface management of tactical 
digital equipment and software." 

On 3 November 1971 TADSO published its first Tactical 
' Digital Standard (TADSTAND 1) [{kRef. 2] which established the 
AN/UYK-7 processor as the standard computer for shipboard 
applications and the CMS-2 high-level language as the 
Standard high-level language to be employed in the 
production of Operational programs for tactical data 
Systems. TADSTAND 1 also provided that a request for 
deviation from these standards could be initiated to TADSO 
1f it was thought to be in the best interests of the Navy to 
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use either another Navy computer or a computer not presently 
in the Navy inventory. 

In response to TADSTAND 1 some reguests to deviate from 
the UYK-7 standard were received. The most significant 
justification given was that the UYK-7 was too large and 
expensive ($720,000 average cost) for the intended 
application. (See App. A for a description of the UYK-7 
computer.) Out of this identified need for a smaller 
computer grew the AN/UYK-20(V) Data Processing System (DPS), 
the Navy standard minicomputer. 

It is the purpose of this chapter to establish the 
meaning and implications of the terms "minicomputer" and 
"standard", to identify the capabilities needed within the 
Navy in a standard minicomputer system, and to establish 
whether or not these capabilities could be met by a small 


computer existing in the Navy inventory in 1972. 


A. DEFINITION OF A MINICOMPUTER 


Commercially available computers in 1972 formed almost a 
continuous spectrum in size, power and capabilities. 
Naturally, it is is difficult to separate the mninicomputer 
from larger or smaller types. 

The possibility of a small computer with useful 
Capabilities and memory capacity grew with the development 
of hybrid and integrated circuits in the mid-1960's. In 
1970 medium- and large-scale integration was introduced, 
allowing even more capability to be designed into a small 
package. At the same time these advancements were reducing 
hardware costs at the rate of an order of magnitude per 
decade. The advent of hini-peripherals specifically 
designed for use with minicomputers was the final addition 
to complete, low-cost mini-systems. At that time, as was 
still true in 1976, software was the predominant cost of 


such systems. 
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C. Weitzman (Ref. 11] defined the minicomputer as an 8~ 
to 18- bit word size machine with memory size from 1K to 32K 
words. Costs range from $4,000 to $100,000. The 
minicomputer is generally catagorized as having limited 
accuracy, low speed for double-precision arithmetic 
operations and no floating-point hardware. By 1972, 
however, Many minicomputers had multiple Input/Output (1/0) 
access features and microprogrammable central processors 
allowing extensive instruction repertoires with firmware 
implementation of floating-point and special mathmatical 
functions. A more detailed discussion of the minicomputer 
technology of the early 1970's may be found in Chapter IV, 
section B. 


Be. DEFINITION AND IMPLICATIONS OF A "STANDARD" 


A "standard" could be defined as a Specific entity which 
will be used in every application where an entity of that 
general description is required. 

The contents of the several TADSTANDS published by TADSO 


imply the following Navy policy concerning a “standard": 


The entity identified as a "standard" will be used in 
all developing and future tactical digital system 
applications except where deviation is specifically 


provided for, requested and approved. 


References 3 through 9 are the standards promulgated by 
TADSO as of May 1976. The impact of such standards in user 
system design will be discussed in Chapt. IV. The 
1mplications of establishing standards are summarized in the 
following paragraphs. 

Standardization allows realization of the economies of 
large scale production. For example, as of May 1976, 824 


AN/UYK-20 Data Processing Systems had been ordered and 637 
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units delivered. At that time there were 107 programs using 
the system.[Fig.2] At the outset of the UYK-20 acquisition 
the estimated production run was in excess of 4500 units. 
This volume is over an order of magnitude greater than any 
one program would require in an independent processor 
acquisition. Clearly, the economies of scale would be 
realized with such a program. Although it is impossible to 
quantify the actual savings realized by using UYK-20 in any 
particular project, the economies of scale are demonstrated 
in the volume order prices for an AN/UYK-20(V) DPS basic 
configuration in fiscal year 1974: 


Quantity - 50 at $25,966 each 
Quantity - 100 at $24,735 each 
Quantity - 150 at $24,324 each 


It is also interesting t> note that the Piscal Year (FY) 
1976 order price for a Similar configuration is about 
$25,000 each, approximately the same as the FY 74 price 
despite inflation. 

Standardization realizes cost savings in material 
support. One project manager estimated that the cost of 
introducing one new part into the Navy Supply System at SPCC 
1s about $1500. It has also been estimated that the Navy 
realizes $20,000 to $40,000 per year in Integrated Logistic 
Support (ILS) cost savings through a standardized systen 
like UYK-20. 

Standardization avoids duplication of support software 
costs. A project manager estimated a savings of $2,000,000 
to $4,000,000 per year in software maintainance costs for a 
project uSing a standard computer. 

Standardization reduces the scope of required 
Maintenance training. The Chief of Naval Technical Training 
emphasized this fact in a letter to the Director of TADSO, 
pointing out that it was becoming increasingly difficult to 


fill technical training billets, and that standardization 
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programs like AN/UYK-7 help alleviate this problem.{Ref.10] 
It is estimated that about $409,000 per year savings in 
technical training costs is realized through the existence 
GemuY K-20. 

Standardization can reduce the amount of training 
required for operator personnel. Lack of standardization 
May mean that as an operator is transferred from one command 
to another he must be sent back to school to learn new 
equipment. Such an occurrence has a direct impact on fleet 
readiness and personnel training costs. AS an example, the 
REWSON program faces this problem because some of its shore 
installations utilize DSC PDP-11 computers while the 
associated shipboard installations employ AN/UYK-20 Data 
Processing Systems. 

Standardization saves the repetitive acquisition costs 
of procurements of unique systems. These costs include the 
recurring costs for ILS, software maintenance, etc. and also 
the one-time development costs. As an example, the UYK-20 
acquisition required $1.3 million in Research & Development 
funding for militarization of commercial hardware, support 


software, documentation, etc. 


Despite these strong arguments in Tavor of 
standardization, there is much resistance to any 
standardization prograag. ee Howard Gantzler, Deputy 


Assistant Secretary of Defense (Installations & Logistics), 
recognized that attitude when he stated at a seminar given 


at the Naval Postgraduate School in January 1976, 


"Everybody is in favor of it [standardization], but 


nobody wants to adopt someone else's standards." 


Rear Admiral E. B. Fowler, Vice Commander of the Naval 
Electronics Systems Command identified another drawback of 
Standardization in an address to the Naval Postgraduate 
School chapter of the IEEE in April 1976. 
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"you have to standardize. You can't afford not to do 
so. But you must also get a firm grip on the half-life 
of the thing you are standardizing... AN/UYK-20 was 
thought at first to be a five year investment. We are 
currently reprocurring, and it looks like ten to 
fifteen years. The CP-642B's [CP-642B computer (UNIVAC 
1212). See Chapt. II, Sect. D.}] have been around for 
sixteen to seventeen years, and we put them on the 
Nimitz, the newest capital ship. This is a systems 


engineering problen." 


In that statement Admiral Fowler suggests that once a 
standard is established, it may be used for many more years 
than anticipated unless a firm policy for replacement is 
adopted at the outset. Understandably, the majority of 
Opposition to standardization was found by this author in 
the technical community, which must design systems using 
standardized components not specifically tailored to the 


tasks required. 


C. THE RANGE OF CAPABILITIES NEEDED 


In January 1972, a Design Review Group (DRG) was 
convened by TADSO to translate the requirements of the Navy 
for a minicomputer system into a specification which could 
be used as the basis for competitive bidding. teas 
significant to note that the intent was not to fill the 
entire range of size and power below the UYK-7, but only to 
fill the identified current and future needs. Thus, from 
the outset the success of UYK-20 depended on accurate 
prediction of those needs py the DRG. The composition of 
the DRG was most important, and it is interesting to note 
the commands represented: Naval Ordnance Syst2ms Command 
(ORD-532), Naval Ships Systems Command (SHIPS~03524), Naval 
Air Systems Command (AIR-5333P), Naval Ships Zngineering 
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Center (SEC-6178D and SEC-6172), H. Q. Marine Corps (Code 
AAM-4), Fleet Combat Direction System Support Activities 
Pacific and Atlantic, and Naval Weapons Laboratory Dahlgren. 
The Naval Ordnance Systems Command and the Naval Ships 
Systems Command have since been combined into one command 
designated the Naval Sea Systems Command (NAVSEA). Thus all 
the commands responsible for systems development were well 
represented. 

In order to save time and development costs, TADSO had 
conceived an "off-the-shelf" procurement. That was an 
important decision, which implied that the intent was to 
procure a market-tested computer system which would only 
need to be militarized. 

Since the computer was to be general purpose and serve a 
wide range of diverse applications, a modular building block 
approach was conceived. A basic configuration was to be 
specified and plug-in modules provided so that the user 
could increase the size and power of the processoc up to his 
individual needs. Add-on modules were to be individually 
priced so that the user only paid for the capability ne 
needed. The following paragraphs summarize the range of 
capabilities which TADSO and the DRG foresaw would be needed 
to meet Navy systems requirements of 1972 and about five 


years into the future. 
1. Packaging 


The computer would be required to meet military 
specification MIL~E-16400 for shipboard, groundbased, and 
submarine electronic systems. This decision precluded 
airborne applications of the computer, which would have 
required the more stringent and expensive MIL-E-5400 
specification, but would have expanded the applications and 
thus the volume of production. The reason behind that 
decision was the intention to produce an interin standard 
Shipboard computer to be eventually replaced by the 
All-Applications Digital Computer (AADC) which was’ then 
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under development by the Naval Air Systems Command (NAVAIR). 
The AADC never materialized, and as of 1975 the AADC project 
had been redirected to produce an Interim Standard Airborne 
Digital Computer ({ISADC). Out of the ISADC project came the 
AN/AYK-14 computer in 1976. 

The computer was to be packaged in one enclosure of 
maximum dimenSions 26 inches high, 24 inches deep, and width 
suitable for mounting in a standard 19-inch rack. Maximun 
power consumption was to be one kilowatt. 

To achieve the desired building block capability, 
the following units were to be strictly plug-in with no 
other hardware changes necessary”"“to install: memory modules 
of 8K-words per module, I/0 channels in groups of two if 
serial and in groups of four if parallel, real-time clock, 


general registers, and microprogrammable control memory. 


We 


2. Reliability and Maintainability 





In accordance with MIL-E-16400, modular construction 
was specified. All assemblies with a cost of $200 or less 
would be throw-away components. Only those assembiies where 
it was determined that repair would be more cost-effective 
than throw-away/replacement would be designated as 
repairable modules. It was further specified that repairs 
would be performed by the contractor, a factor which had a 
later impact on the repairable turn-around time. 

The maximum configuration of the computer was to 
have a Mean Time Between Failures (MTBF) of 2000 hours, a 
Mean Time to Repair (MTTR) of 15 minutes and a Maximum Time 
to Repair of 120 minutes. The MTBF specified was a figure 
which had been used On previous military computer 
Specifications. As far as the author of this thesis could 
determine, the basis for citing the 2000 hour figure was 
historical rather than the result of calculation. 

The computer was to be logically and electrically 
designed to facilitate the isolation of malfunctioning 


modules through diagnostic programming. The diagnostic 
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program was to isolate 95% of recurring (non-intermittent) 
active logic element failures to not more than three printed 


circuit card modules. 
3. Architecture 


The computer was to employ enlEd generation 
technology with the use of medium-scale integration. 


Perhaps the most Significant architectural 
requirement was that the processor was tobe: 
microprogrammable. The rationale for requiring this 
a 


capability was the possibility of a more powerful 
macro-instruction set and the flexibility to modify or add 
to the Mmacro-instruction set by simply modifying the 
contents of control memory. An additional requirement was 
therefore for at least 500 words (16-bit) of user growth 
capacity in the control memory. 

Other reguired architecture attributes were: word 
length at least 16-bits including Sign but not including 
parity, random access non-volatile menory with a separate 
high speed memory desireaple but not reguired, main memory 
read-restore cycle time less than 1.2 microseconds, 
asynchronous timing with at least one level of memory fetch 
instruction overlap to create an effective memory cycle time 
of less than one microsecond, minimum storage capacity of 
8K-words expandable EO at least 65K-words (directly 
addressable) in 8K-word increments, a minimum of four 
general registers expandable to sixteen. 

It was Significant that no requirement was made for 
a capability to expand memory capacity beyond 65K-words. 
Also significant was the absence of requirements for parity 
checking, memory write protection or executive mode with 
privileged instructions. 

The guestion of parity checking was a much discussed 
attribute. Those in favor cited the need to identify 
hardware errors, particularly in memory accesses, when 


attempting to debug software. In addition, arguments were 
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made in favor of identifying errors when executing 
operational programs to prevent miscalculations of target 
information, Misrouting of data (particularly in message 
handling systems), mishandling of classified information, 
etc. The arguments against parity pointed to the 
significant cost in real estate (extra bits and about 10% 
more logic) and extra memory bits per word. It was argued 
that parity error detection had little value in modern 
digital equipment since this attribute was designed to 
detect Single bit failures rather than catastrophic logic 
failures affecting whole blocks of addresses; the latter 
type of Failure characterized the type of failure most often 
encountered in modern equipment. Operationally it was 
thought undesireable to interrupt processing of critical 
Merge: data to process parity errors in a combat situation. 

In the end the cost considerations prevailed. 
Although the question of memory protection was not discussed 
to the same extent aS memory parity checking, similar cost 
and real estate savings could be realized by not including a 
hardware memory protection feature in the design. 

The macro-instruction set specified provided for 
Single and double word addition, suptraceron, 
multiplication, division, logical operations, shifts, jumps, 
and a programmable stop. In a non-dual-state machine the 
programmable stop would be non-privileged, making ita 
controversial attribute. Only load, add, subtract and store 
byte operations were specified, and no bit manipulation 
instructions were required. It iS Significant that gar 
Operations specified were arithmetic (recognizing the most 
Significant bit of a word as the sign) so that no capability 
for full 16-bit data manipulation was required. [Instruction 


execution times were specified as follows: 


Instruction Register-to-Register Memory-to-Register 
Add,Subtract 1.2 microseconds 2.2 microseconds 
Load,Store N/A 2.2 microseconds 
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Multiply 9 microseconds 11 -microseconds 
Divide 20 microseconds 22 nicroseconds 
Shift(16—bit) 7 microseconds N/A 


The computer was to be capable of executing not less’ than 
500,000 instructions per second for the following 


distribution of memory-to-register instructions: 


Instruction Type Percent of Mix 
Add, or equivalent 34 
Logical or masking 34 
Branch (Jump) 18 
Multiply 5 
Divide 1 
Miscellaneous | _8 
100 
The choice between one's-complement Or 


two's-complement arithmetic was left to the contractor, 
despite the fact that most previous Navy computers were 
one's-complement machines. That decision would impact on 
future software compatibility and system integration. 

The DRG specified at least single-level indirect 
addressing, indexing, and relative addressing to a fixed 
base which could be program modified. 

A hardware (or firmware) capability to load programs 
(bootstrap) was to be provided. The intent was that the 
bootstrap would be a plug-in option wherein the user could 
Obtain bootstrap capability for the particular peripheral 


and channel desired. 


4. Input/Output 


It was intended that the I/O structure be such that 
the I/O channels access memory through a second memory port, 
eliminating interference with processor operations. This 


requirement meant that an arithmetic unit, data registers, 
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etc. were required for each channel to perform buffer 
control functions, address calculations, interrupt control, 
etc. In order to save on real estate, the channels (a total 
of sixteen) were to be grouped in increments of not more 
than four channels for parallel mode, or two channels for 
serial mode. Only one adder and set of data registers plus 
control circuitry would be required per four channel group. 
This requirement, While saving circuitry and cost placed 
several Significant restrictions on possible I/0 


configurations; 


* For parallel mode data transfer, each four channel 


group was constrained to one type of interface. 


* Serial and parallel channels could not be mixed 


within a group. 


* Double word (32-bit) transfers, such as necessary for 
interfacing with UYK-7, would require one channel 
from each of two adjacent groups, thus forcing eight 
channels to be of the same type of interface. (This 
requirement stems from the need for separate 
processing circuitry for the upper and lower 16-bits 


of 32-bit parallel transfers.) 


Direct Memory Access (DMA) was desired but not 
required. Thus, a provision for direct memory access by a 
high speed mass storage device (such as a disk) could 
somewhat compensate for the lack of provision for expansion 
of main memory beyond 65K-words. 

Various types of interfaces were to be provided as 


options: 


* Parallel (MIL-STD-1397) 
es NTDS Past (-3 volts) 
a NITDS Slow (-15 volts) 
es ANEW (+3.5 volts) 
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‘* Serial 

eukS=232C synchronous and asynchronous’ normal 
speeds 

e MIL-STD-188C synchronous and asynchronous normal 
speeds 

e MIL-STD-1397 (NTDS) 32-bit serial 

e MIL-STD-188C high speed (up to one million bits 
per second) 


All parallel types were to provide full duplex 
Operation in a normal data transfer (16- or 32-bit) mode, an 
intercomputer mode, or an externally specified address (ESA) 
mode. Asynchronous serial channels were to provide 
full-duplex operation at bit rates of 75, 150, 300, 600, and 
1200 bits per second (baud) with 2400, 4800 and 9600 baud 
desireabie. 


5. Interrupts 





A priority structure of interrupts was specified 
With the following types of interrupts required (in order of 
priority, highest to lowest): power failure protection, 
instruction fault, real-time clock overflow, internal clock 
interrupt, intercomputer time-out, external device interrupt 
and I/O interrupts. 

Despite the usefulness of nesting interrupts, the 
specification required only chat interrupts occuring 
Simultaneously be nested. Furthermore, the specification 
required that all interrupts of Lower priority be disabled 


while processing an interrupt. 


6. cControl/Maintenance Panel 


The Specification required that a 
control/maintenance panel be provided that could be, but was 
not required to be separate from the computer. Normal panel 
displays, indicators and controls were to be provided (these 


were specified in detail). Significantly, the panel could 








be configured to display only one register at a time, or 
more, as the manufacturer wished. 


7. software 


It is significant that the question of software was 
not addressed in the Specification generated by the DRG. In 
the Request-for-Proposals (RFP) only an assembler was 
required. 

Appendix B summarizes the specifications for the 
Standard minicomputer system as determined by TADSO and the 
DRG. 


D. CAPABILITIES OF EXISTING NAVY COMPUTERS TO MEET THE 
SPECIFICATIONS 


It is valid to investigate whether the perceived present 
and future needs of the Navy for a minicomputer, as defined 
by the DRG, could be met by an existing general purpose 
small computer in the Navy inventory. If so, this computer 
could be designated a standard just as the AN/UYK-7 had been 
a year before. 

The sections below discuss the pertinent features of 
some of those Navy computers which would have been nost 
likely to fill the need for a standard minicomputer. 
Appendices C through F Summarize the characteristics of 
those computers. 

Comparing the standard minicomputer specification with 
the existing computers reveals that none met the 
specification completely, although two were good candidates 
with certain exceptions. The AN/UYK-15(V) lacked 
mMicroprogramming and relative addressing, but was otherwise 
acceptable. It had additional features such as memory parity 
checking, memory write protection and multi-ported memory 
banks to further recommend it. The AN/UYK-12(V) also lacked 


microprogramming and did not meet all required instruction 


28 











execution speeds or memory capacity, but had an extensive 
support software package to recommend it. 

The existence of UYK-12 and UYK-15 brings the decision 
to specify a microprogrammed processor under close scrutiny. 
As discussed in the previous section, the advantages of 
microprogrammability are an expanded macro~instruction set, 
ability to implement high speed floating-point, mathematical 
and trigonometric functions as needed, and flexibility to 
add high-speed user macros to facilitate real-time 
processing. The disadvantages were best summarized in 
enclosure (1) of a letter to TADSO from the ‘Naval Air 
Systems Command (AIR-5333), 


"The latter deficiency {the requirement for 
micro~programmability ], while being technically 
feasible, leads to unusual hardware and software 
configuration management problems. NAVAIR believes 
that a requirement for micro~programmability has not 
been demonstrated and will serve only to eliminate 


gualified vendors."{ Ref. 13] 


NAVAIR*'s comments about configuration management refer 
to the potential user capability to modify the 
macro-instruction set. It must be pointed out that 
configuration control can be maintained by requiring that 
all modifications to the macro-instruction set be upward 
compatible with the basic set. 

The foregoing comments not-witastanding, 
microprogrammability remained a requirement, and none of the 
existing Navy computers could meet the specification. It is 
also interesting to note that a majority of the computers in 
the Navy inventory were manufactured by the UNIVAC Defense 
Systems Division of Sperry Rand Corporation (UNIVAC). The 
Roln Corporation manufactured AN/UYK-12(V) is an exception, 
and there were others. Comparison of the standard 


Minicomputer specification with the UNIVAC manufactured 
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computers reveals that the DRG was probably influenced by 
the UNIVAC design philosophy le producing their 
specification. For instance, the UYK-12 [I/0 structure, 
which was not in accordance with the specification, was 
Simply another method of accomplishing the same end. It is 
the opinion of this author that the use in the RFP of the 
detailed technical specification produced by the DRG rather 
than a performance specification, probably excluded some 
Candidate minicomputers from the competition. 


1. CP-642B 


This computer, a militarized version of the OUNIVAC 
1212, was an upward compatible follow-on to the 
USQ-20/CP-642/CP-642A family. Designed specifically for use 
in the Navy Tactical Data System (NTDS), its architecture 
optimized processing of large quantities of complex data 
where heavy I/0 comunication was required. With reference 
to App. C it can be seen that although cCP-642B was a 
Rinicomputer in capabilities, it was a physically larger 
unit than desired. Its size and slow speed are a result of 
its second generation architecture. Lack of serial I/0 
Capability, lack of interrupts and limited memory were other 
factors which made this computer unacceptable. Appendix C 
profiles the CP-642B. 


2. AN/UYK-15(V) 


The shortcomings of this computer, a militarized 
UNIVAC 1616, have been previously discussed. Additional 
desireable features incorporated in the AN/UYK-15(V) include 
optional additional general registers up to 64, memory 
parity checking and a priority structured, multi-ported 
memory. This latter feature incorporates a priority 
Multiplexer which provides four access ports for _ each 
16K-word memory bank. Combined with separate I0C's for each 
group of four I/O channels, this feature allows simultaneous 


access to different memory banks by the CPU and various 
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Ioc's, thus improving throughput. Appendix D profiles the 
AN/UYK-15(V). 


3. CP=3 $C 


Commercially designated the UNIVAC 1289, this 
computer was designed for navigation system applications. 
Although of second generation technology, it featured 
reasonable speed. It failed in a number of ways to meet the 
standard minicomputer specification, but it had_ some 
capabilities not required, but desireable: dual states 
(program and executive), programmable memory read/write 
protection, memory parity checking, and floating-point 
hardware. Appendix E profiles the CP-890. 


4, AN/UYK-12(V) 


That computer was designed from the ground up as a 
militarized Data General NOVA with a military application 
I/O structure added. Designated the Rolm 1601, it was 
completely upward compatible with the NOVA and could thus 
run all software developed for that popular minicomputer. 

The I/O structure was basically a single f[I/0 bus 
With the facility to address 61 different devices. Each 
device could independently interrupt the processor according 
to a predetermined priority. The computer could be 
configured with up to 16 I/O interfaces and 15 backpanel 
connectors. 

An extensive package of well-tested and 
well-documented support software was available. Included 
were cross-assemblers and cross-compilers so that programs 
for the UYK-15 could be assembled or compiled on a larger 
machine. That feature recognized the constraints on uSing a 
Minicomputer for program development. 

In this chapter the meaning and implications of a 
Standard minicomputer have been established. The Navy 
requirements for a minicomputer system in 1972 were 


discussed, and it was concluded that no existing small 
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computer in the Navy inventory could meet those 
requirements. In Chapt. III the history of the standard 


minicomputer acquisition project will be discussed. 
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III. DEVELOPMENT AN 


The events leading to the publication of a specification 
for a standard minicomputer have been detailed in the 
previous chapter. This chapter will relate the history of 
the AN/UYK-20(V) acquisition from specification to mid-year 
1976. Much of the information on events leading to the 
contract award in May 1973 was derived from a research paper 
by Captain J. S. Sansone [Ref. 14], who was the Project and 
Contracting officer EG the standard mMinicomputer 
procurement. 

In June 1972 the preliminary specification for the 
standard minicomputer was distributed for final review. By 
that time TADSO was well established and had issued six 
TADSTANDS On a variety of subjects. [{Refs. 2-8] The 
acquisition strategy called for Wilatdrization of a 
commercial system requiring a minimum of system development 
to meet the DRG specification. It was estimated that about 
$1.8 million in ReSearch, Development, Test and Evaluation 
Navy (RDT&EN) appropriated funds would be necessary to cover 
costs of design and development, militarization, Government 
Furnished Equipment (GFE), environmental and reliability 
testing, TEMPEST testing, Integrated Logistics Support 
plans, development of technical manuals, other data 
requirements, and support software development. 

In late August 1972 CNM advised cCNO's Director of 
Research, Development, Test and Evaluation (OP-098) of the 
existance of the standard minicomputer specification, and 
the need et prompt approval to preclude further 
proliferation of commercial minicomputers in the Navy 
inventory. OP-098 was also informed that the necessary $1.8 
Million in RDT&EN funds could be obtained by reprogramming 


Fiscal Year 1973 funds from sub-allocations to the various 
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projects who would use the standard minicomputer. Since the 
amount of funds to be reprogrammed did not exceed $2 
million, prior approval from the Secretary of Defense 
(SECDEF) and the Armed Services and Appropriations 
Committees of Congress was not required. Reprogramming 
could be carried out within the Department of the Navy with 
the approval of the budget activity sponsor (OP-098). There 
was sufficient justification for this plan -since the user's 
funds would have been used for a computer procurement 
anyway. However, the plan raised potential user project 
Manager objections. First, control over the design and 
development of the minicomputer would be taken out of the 
hands of the project managers and vested in an independent 
office. Second, great risks were involved in the delivery 
schedule. Third, ELEX-560 could not have the specific needs 
of all the user projects at heart when making tradeoff 
decisions regarding cost, schedule and performance. 

By mid-September 1972 the approval of CNO was assured. 
CNM tasked the Commander, Naval Electronic Systems Command 
(COMNAVELEX) to handle the procurement. In response, 
COMNAVELEX created a division Within his Material 
Acquisition Directorate (ELEX-05) to carry out this task. 
The division was designated the Standard Tactical Digital 
Equipment Division (ELEX-560). [Fig. 3] At this time the 
procurement plan specified a formally advertised two-step 
procurement based on the DRG specification and resulting in 
a firm-fixed-price contract. 

In October 1972, in response to fTADSTAND 1, TADSO 
received a request from the Mk68 Gunfire Control System 
(GFCS) project to deviate from the UYK-7 standard in favor 
of a commercial minicomputer. The request was subsequently 
denied, and the requirements of the Mk68 GFCS project became 
the first firm requirements for standard Minicomputer 
systems. The constraints of the Mk68 GPCS project schedule 
were thus imposed on the standard minicomputer procurement. 


The new schedule constraints forced abandonment of the 
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formal two-step procurement in favor of an accelerated plan. 
The plan called for a negotiated procurement under 
paragraphs 2304 (a) (2) and (10) of Title 10 of the United 
States Code. Those regulations allowed a negotiated 
procurement in lieu of a formally-advertised, sealed-bid 
competition in cases where the exigency would not permit the 
delay incident to formal advertising and when it was 
impractical to obtain competition. Significant milestones 


adopted were: 


* Issuance of the Reguest for Proposals (RFP) by 1 
December 1972 


* Award of the contract by 22 February 1973 


* Delivery of the first Functional Demonstration Models 
(FDM - non—-militarized prototype) 30 days after award 
of contract 


* Commencement of testing by 22 September 1973 


* Delivery of the first Advanced Production Engineering 
Models (APE - militarized prototype) nine nonths 


after award of contract 


* Delivery of the first production units by May 1974 


Technical evaluation (TECHEVAL) would be completed in the 
contractor's plant and operational evaluation (OPEVAL) would 
be completed concurrently with the OPEVAL of the first user 
system. A firm-fixed-price contract was anticipated. The 
accelerated plan precluded detailed analysis of proposals to 
determine which contractor offered the best performance per 
price. It was planned to simply select the lowest bidder 
among those found responsive to the DRG specification. 
Thus, little improvement on the DRG design was possible 
through the acquisition process. 

On 15 November 1972, CNM declared the DRG specification 


as the Navy standard minicomputer specification and 
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constrained all projects planning or procuring minicomputers 
to use the standard as Government Furnished Equipment unless 
approval was obtained from TADSO to deviate. [Ref. 15] Three 
projects in addition to Mk68 GFCS were specifically directed 
to switch to the standard minicomputer for their production 
‘phase: the SPS-48 Radar Improvement Program, which had gone 
through development with the AN/UYK-15(V) computer; the 
Carrier Tactical Support Center project (CVTISC), which had 
gone through development with the IBM SP-1 computer, and the 
Satellite Communications program (SATCOM), which had gone 
through development with the Rolm Corporation 1602 computer. 
This directive was probably premature since all projects 
were then forced to include in their production plans a 
component that was only a piece of paper with no proposals 
in hand to guarantee the feasibility of meeting the proposed 
schedule milestones. 

The establishment of the specification as a standard 
resulted in identification of more projects requiring a 
minicomputer. AS of mid-November 1972 estimated 
requirements for some 314 production units (through Fiscal 
Year 1974) had been identified. Since this figure was 
expected to change, and delivery dates were not’ known, 
ELEX-560 proposed an Indefinite Delivery, Requirements type 
contract. Competition would be based on unit price per lot 
quantity for a specified system configuration plus prices of 
certain add-on modules. By mid-November 1972, 25 firms had 
indicated a desire to submit proposals and none were thought 
to be unresponsive. A fully competitive procurement seemed 
assured. 

The RFP released on 1 December 1972 cited the milestones 
previously listed and a three year production run. Each 
year's production was an option to be priced separately so 
that the ccntractor could protect himself fron inflation. 
The RFP contained estimated production requirements for each 
year to protect the contractor from the high risks of 


bidding on unknown production quantities. Production funds 
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would be obtained directly from the users at the time thev 
placed orders under the annual Requirements Contracts. The 
RFP also specified a government option for rights to the 
technical data to provide for a competitive follow-on 
procurement. 

At this point some comments should be made about the 
acquisition strategy. First, a great deal of the success 
hinged on obtaining adequate competition. Without it, there 
would be 1littie to choose from as far as system design and 
price. Second, the desire to select the lowest bidder 
precluded opting for a better design at a slightly higher 
acquisition cost, thus achieving better performance and 
reliability and possibly a lower overall life-cycle cost. 
Third, unless later funding for the standard minicomputer 
project was forthcoming from Operations & Maintenance Navy 
(OS6MN) appropriated funds, the users would bear the costs of 
Support software Maintenance and enhancements, system 
improvements, maintenance of documentation and other support 
costs. This was a point that worried user project managers. 
Put Simply, if the orders stopped the funding would stop, 
and the system would no longer be supported. 

By the end of December 1972 the estimated award date had 
Slipped to 1 March 1973 because of changes to the RFP. 
Those changes resulted from substitution of the CVTSC 
project requirements for the Mk68 GFCS requirements when the 
latter project's funds were cut. At that time there were 
also growing complaints from interested companies that the 
RFP closing date was too soon, the specification was too 
restrictive, and the delivery date for FDM's was 
unrealistic. Because of these points, plus the unspoken 
consensus that the specification favored one company's 
design philosophy, about 19 of the original 25 interested 
firms declined to submit proposals. Included in these 19 
were IBM Corporation, Rolm Corporation, Control Data 
Corporation (CDC), and Digital Equipment Corporation (DEC). 


The competition was rapidly vanishing. 
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The options open to the Navy at this point were as 
follows: 


* Maintain the schedule despite the high probability of 


a sole-source procurement. 


* Slip user project schedules in order to extend the 


proposal due date and gain more competition. 


* Cancel the RFP and restructure the procurement as a 
development effort. 


The decision was to slip the closing date for receipt of 
proposals to 2 April 1973 and extend the date for delivery 
of FDM's to 120 days after date of contract. Since this 
schedule might not meet some potential user schedules, a 
risk of losing some firm requirements had been accepted. 

During the month of February 1973 two formal protests on 
the RFP were filed with the Government Accounting Office 
(GAO). The first, from Control Data Corporation, was 
Satisfied by the extension of the due date for provosals. 
The second, from UNIVAC, objected to the extension on the 
grounds that the company had spent considerable effort and 
funds to meet the original dates. An important point 
brought out in this latter protest was that no firm had a 
computer that would neet the specification completely, and 
that substantial design and development effort were 
necessary in all cases. SAO subsequently determined that no 
violation of procurement law had occurred, and JUNIVAC's 
protest was denied. 

Although not required for a procurement of such low 
estimated dollar value ($1.8 million), a Source Selection 
Authority (SSA), Source Selection Advisory Council (SSAC), 
and Source Selection EValuation Board (SSEB) were 
designated. The SSEB consisted of the DRG plus 
representatives of NAVELEX, the Marine Corps and TADSO. The 
SSAC consisted of representatives of NAVELEX and TADSO with 
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expertise in management systems, cost analysis, logistic 
Support, etc. The SSA was COMNAVELEX with the advice and 
consent of CNM. 

On 2 April 1973 proposals were received from UNIVAC, 
CDC, General Electric and Raytheon. The SSEB proceeded to 

Without knowledge of prices and found 
all firms to be responsive to the DRG specification. The 
SSAC determined that adeguate price competition existed. A 
pre-award survey was conducted at each plant during the week 
of 16 to 20 April 1973. All offerers were found to be 
technically and financially responsible and responsive in 
accordance with Armed Services Procurement Regulation (ASPR) 
1-903. Contract award was made to the low bidder, UNIVAC, 
Stire2z? April 1973. The contract included all hardware 
reguirements plus an assembler for a firm-fixed-price of 
$673,000. 

Soon after contract award, user requirements for 
additional support software in addition to the assenbler 
were identified. To meet this need, sole-source contracts 
were let to UNIVAC for two self-hosted systems. The first, 


designated ‘Level I, was released in November 1973. The 


second, designated Level II, was released in January 
1974.{App. G] NAVELEX also contracted with UNIVAC at that 
time to develop two other support software packages: a 


standard real-time executive later designated SDEX-20, which 
was to provide users with bpaSic software moduies upon which 
to build their operational programs; and a compiler for the 
Navy standard high-level language (CMS-2), which would 
generate machine code for the UYK-20. This high-level 
language for the UYK-20 was designated CMS-2M and was to be 
a subset of the CMS-2 language. These additional contracts 
were funded from the balance remaining of $1.3 million in 
RDT&EN funds reprogrammed for the UYK-20 acquisition. 

In May 1973 TADSO revised TADSTAND 1 to designate the 
UYK-20 as the Navy Standard digital processor for those 


applications requiring a minicomputer. {Ref. 3] As expected, 
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this action generated a few requests for deviation from that 
standard. Most were turned down. The Submarine Integrated 
Radio Room (IRR) project, which was developing with the CDC 
MPP computer and the AN/UYK~-15(V), had a request to deviate 
denied on the basis that the UYK-20 was upward compatible 
With the UYK-15. Very few requests for deviation were 
granted. The VERDIN retrofit project was granted a waiver 
due to size problems in retrofitting equipment into a 
submarine, and the necessity for compatibility with existing 
equipments. The SEA SCOUT project was granted a waiver 
since two systems were already deployed with the 
AN/OYK-12(V), urgent requirements existed for four nore 
systems, and no more than a total of six systems were to be 
acquired. The BULLSEYE project was granted a waiver to use 
the DEC PDP-11 computer as its shore-site cryptologic 
processor. Justification for that waiver was that the 
PDP<11 was currently in use at shore sites, associated 
engineers and support systems were available, and shipboard 
use was not anticipated. 

On 27 March 1974 the UYK-20 received service approval. 
A major miiestone in any program, this event also had a 
profound impact on the funding of the project. Once service 
approval was received, the activities of ELEX-560 could no 
longer be supported with RDT&EN funds. Since no Operations 
& Maintenance Navy (O&MN) funds were available to support 
the project, NAVELEX was forced to assess users of the 
System for system support in the following manner. The 
UYK-20 contract was a Requirements, Indefinite Delivery 
Contract which allowed the users to purchase systems and 
components by transmitting a DD Form 1155 (Order for 
Supplies or Services) to ELEX-560 with an order form 
attached. The user's funds were obligated via the DD Form 
1155, and the order form provided a detailed description of 
the equipment and software requested. The user obligated 
funds according to a published price list. These published 


prices included a surcharge over the fixed prices in the 
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contract; it was this surcharge which was used to fund 
ELEX-560 support activities. 

Occasionally users would reguire new system components 
(e.g. bootstraps, I/O interfaces, and/or peripheral handler 
software routines OL a unique peripheral device). 
Naturally the requesting user had to provide funds for the 
development of his ‘unique requirement. This was 
accomplished by submitting a DD Form 1149 (Requisition and 
Invoice/Shipping Document) to ELEX-560 with a description of 
the needed material. ELEX-560 would use the authority 
transmitted by the DD Form 1149 to obligate the user's funds 
on a sole-source Time and Materials type contract with 
UNIVAC for the development effort. 

Accounting for the surcharge and the myriad of 
appropriation budget activities cited by the users was an 
elaborate task. Frequent liason with ordering activities 
waS necessary to insure that surcharges were "paid" out of 
appropriation catagories which could be properly used by 
ELEX-560. For the most part O&MN funds were required to 
fund project tasks. 

The surcharge system concerned uSer project managers. 
Primary objections were (1) the necessity to pay prices 
above the fixed prices on the contract, and (2) the 
realization that if no orders were received the funding 
Support for the project would dry up. Each year NAVELEX 
requested sufficient O&MN funding to support the project, 
but those funds were never forthcoming. Project personnel 
believed that the project requirements were cut from the 
Navy budget submission by the Office of the Secretary of 
Defense (OSD) or the Office of Management and Budget (OMB). 

In September 1974 the first issue of "The Standard" was 
published. This dccument was, as stated in its header, "a 
bi-monthly newsletter published to inform AN/UYK-290 users of 
current status and new developments that involve the 
AN/UYK-20(V) computer and its support software." "The 


Standard" was a step toward solving the communications 
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»scroblem that plagues all bureaucratic organizations. 

About that same time the idea of a formal user's 
»rganization was conceived, and in November 1974 the first 
IN/UYK-20 User's Group meeting was held at the Naval 
tlectronics Laboratory Center (NELC) in San Diego. The 
neeting attracted some 200 persons from government and 
PF vate industry. By mid-1976 the AN/UYK-20 User's Group 
os meeting semi-annually in the Spring and Fall and boasted 
, membership of close to 300 persons. Each meeting provided 
j forum for ELEX-560 to transmit further information to the 
Mears, but more importantly for the users to present ideas 
in briefings and presentations which would benefit other 
users. The meetings also provided an opportunity for users 
and project cffice personnel to meet face to face and 
discuss problems. 

At the November 1976 User's Group meeting at the Naval 
Postgraduate School in Monterey, the Fleet Combat Direction 
Systems Support Activity (FCDSSA) San Diego announced the 
release of a compiler for the UYK=20 computer. mies 
compiler, designated CMS-2Y(20), operated under the SHARE/7 
operating system on the AN/UYK-7 computer. The compiler was 
designed to provide versatile program development 
capability, Since it utilized the powerful programming aids 
available under SHARE/7. {App. G] 

BY late-1974 the first UYK-20 computers had been 
received and were in use in the development of tactical 
systems. Many hardware failures were encountered in these 
early computers. The hardware problems were compounded by 
the fact that the diagnostic program package for the UYK-20 
was not available to users until November 1974. Users were 
dependent on UNIVAC field engineers to perform corrective 
Maintenance. Errors were also encountered in the support 
software and in the documentation for both hardware and 
software. In general these problems were discovered and 
solved through trial and error, but with large expenditures 


of user time and funds. 
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The types of problems most often encountered during the 
early period in late-1974 were: Memory Array Board failures, 
Memory Control Board failures, broken or bent connection 
pins on printed circuit (PC) cards, defective power 
supplies, PC cards not seated properly, and software 
documentation which either contained erroneous descriptions 
of software capabilities Or neglected to mention 
Capabilities that existed. The contractor, who was 
responsible for correcting many of the problems, submitted 
Engineering Change Proposals (ECP's) to NAVELEX to correct 
deficiencies. Because of a clause in the contract which 
reguired all production units to he identical, a retrofit 
was necessary to incorporate the approved Engineering 
Changes into production units already in the field. UY K-20 
serial number 350, which came off the production line in 
December 1975, became the baseline unit for the first 
retrofit. All 349 previous production units were affected 
in varying degrees. Retrofit I consisted of minor changes 
such as replacement of screws, mountings, and fittings, and 
major changes such as replacement of power supplies in 
serial numbers 1 through 12, replacement of PC cards which 
had been redesigned, and modifications to existing cards. 
The retrofit was performed in the field by UNIVAC engineers 
during the period from January 1975 to September 1976. 

Despite the discovery and correction of many 
deficiencies, by mid-1975 the frequency of failures in 
production units signified that a reliability problem did 
exist. Perhaps the best data base attesting to the 
suspected reliability problems came from the Naval 
Electronics Systems Engineering Center (NESEC) at San Diego. 
This activity was tasked with assembly and checkout of the 
Navy Message Address Communications System (NAVMACS), which 
Was one of the first systems using UYK-20 to reach the 
fleet. During the period late-1974 to mid-1975, NESEC San 
Diego reported that a high percentage of production units 


were received inoperative due to faulty PC cards and 
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assembly modules. Spares received were also defective, 
making trouble-shooting with the diagnostic programs very 
difficult. (Trouble-shooting procedures utilizing the 
diagnostic rcutines depended on substituting spare modules 
and PC cards for suspected defective parts.) Some failures 
were intermittant, making them extremely difficult 0 
diagnose. 

Records at NESEC San Diego indicate that during the 
period late-1974 to mid-1975 many modules were experiencing 
60% to 70% failure rates. Particular problem areas were 
power supplies, Memory Array Boards, seating of I/O cards, 
and overheating in hot weather. It was found that over a 
Significant period of operation, however, the failure rate 
would be substantially decreased, indicating that a 
"burn-in" period increased reliability. 

In response to the reports from WNESEC San Diego, 
personnel from UNIVAC visited that activity and verified the 
need to upgrade reliability. In June and July of 1975 
UNIVAC voluntarily Shut down the production line in 
Clearwater, Florida to investigate the possibility of severe 
Quality Assurance (QA) problems. Over the ensuing months 
the contractor took the following action to up-grade UYK-20 
guality: 


* Personnel Improvements 

» Established QA as an independent organization. 

» Transferred added QA technical and management 
capability from the main plant in St. Paul, 
Minnisota to the UYK-20 production plant in 
Clearwater. 

» Hired additional quality engineers and 
inspectors. 

2» Added a program QA man in Clearwater. 

ea Transferred final testing to Manufacturing in 
order to remove schedule concerns and increase QA 


focus. 
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| * Documentation and Procedures 

s Reviewed and updated all inspection and test 
procedures. 

« Established formal procedures for resolving 
Defense Contract Administration Service (DCAS) 
and UNIVAC quality concerns and for implementing 
corrective actions. 

» Reviewed and improved assembly processes. 

s Added automatic equipment. 

e Introduced new material handling containers for 
PC cards. 

s Developed new fixtures for holding memory arrays 


during assembly. 


Re 


* Training and Motivation 
»e Hired a full-time trainer. 
e Fstablished a dedicated training roon. 
es Instituted training programs for manufacturing 
and inspection personnel. 
e Established certification criteria and 


recertification time periods for all key skills. 


* Management Reviews 
» Increased local audits. 
» Fstablished formal defect trend reviews with 
manufacturing and QA. 
» Implemented corrective action follow-up on key 
defects. 


a Strengthened and increased management audits. 


After the June to July shutdown and the subsequent 
quality improvement program, UNIVAC experienced a 66% 
improvement in acceptance tests at the Clearwater plant. 
These improvements were felt by the users in late-1975 when 
a high percentage of computers received from the factory 


were in operational condition. 
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In late-1974, in response to user demands, JUnivac 
developed a User's Handbook for the AN/UYK-20(V) DPS. This 
handbook was written primarily for operational program 
development programmers and contained a description of the 
hardware and detailed descriptions of support software. The 
handbook was first released in early-1975 and by mid-1976 
had undergone four major revisions to correct numerous 
errors and incorporate new software systems. 

Early in 1975 SDEX-20 (the Standard Real-Time Executive) 
and the CMS-2M compiler were released. Since CMS-2M was a 
subset of the CMS-2 standard high-level language, it became 
a standard also. UYK-20 users were required to write their 
Operational programs in that language. A few projects had 
begun development using other languages, predominantly 
FORTRAN, and were unwilling to rewrite. Their objections 
cited Schedule impact, increased development cost and the 
high risk associated with using an untested compiler. TADSO 
held a firm line, and most projects still in development 
were forced to switch to CMS-2M. 

Up to the beginning of 1975 no peripheral devices 
existed which were specifically meant for use in Navy 
tactical systems. It waS rapidly becoming apparent that 
proliferation of diverse peripheral equipments was also a 
problen. By May 1975, 76 unique peripheral devices were in 
use with the UYK-20 computer. In February and March of 1975 
two contracts were let for peripheral devices which were 


destined to become standards for use in Navy systems: 


* A contract with QUANTEX, Peripherals Division of 
North Atlantic Industries Incorporated £Or a 
Cartridge Magnetic Tape Unit (CMTU) which was 
eventually designated AN/USH-26(V). 


* A contract with UNIVAC. for an Alphanumeric Display 
Device (ADD), which was eventually designated 
AN/USQ-69(V). 
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The acquisition strategy for these peripheral units was 
identical to that utilized in the standard minicomputer 
procurement. Requirements, Indefinite Delivery, 
firm-fixed-price contracts were awarded to the low bidders 
among those contractors found responsible and responsive to 
the RFP. The first standard peripheral production units 
were scheduled to be delivered in October 1976. 

AS a result of its diversification into peripheral 
eguipments and other areas, at the beginning of Fiscal Year 
1976 ELEX-560 was redesignated the Automatic Data Processing 
(ADP) Systems Division (ELEX-570). With the redesignation 
came increased scope of responsibilities including: 


* Tactical ADP hardware development. 
* Tactical ADP software development. 


* Tactical ADP display systems development. 


In September and October of 1975 the Disk File Manager 
software and Machine Independent System Generator software 
packages were released. [App. G] 

In November 1975, at the AN/UYK-20 User's Group meeting, 
it was announced that a User's Group Software Directory 
would be published quarterly by the Publications Chairman of 
the User's Group. This directory was designed to inforn 
users of the availability of operational and Support 
software developed by other users. Although the concept was 
good, by May 1976 there were no suppliers of information on 
their software, although there were many requests for the 
directory. 

Also announced at the November 1975 meeting was an 
AN/UYK-20 Test, Analyse and Fix (TAAF) progran. This 
program, to be carried out at the Naval Weapons Center at 
Dahlgren, was designed to accomplish the following 


objectives: 


* Perform a Navy conducted AN/UYK-20 reliability test 


49 











tO § 
a Ensure recently retrofitted field changes 
improved UYK-20 operation. 
se Detect any additional changes required to 
demonstrate a 2000 hour MTBF. 


* Establish a UYK-20 field data collection progran. 


The test setup was to consist of four machines variously 
configured to excercise all hardware options. A total of 
12,9000 hours of operation under steady-state temperature, 
voltage and frequency conditions was planned. Two of the 
Machines were to be subjected to a total of 600 hours of 
Vibration testing. In May 1976 the results of the TAAF 
program were reported to the User's Group assembled at the 
Naval Underwater Systems Center in New London: 


* Corrective Action Items Identified 
we Memory Array Board fabrication popped resistors 
and cracked cores. 
«a The master clock was overloaded. 
«s Miscellaneous logic gates were overloaded. 
»s A certain type of Read-Only-Memory (ROM) was 


defective and should be replaced. 


* Corrective Action items Installed 
es An Engineering Change Eo eliminate clock 
overload. 
«s Increased QA inspection of Memory Array Boards 


and Power Supplies. 


* Observations 
«s No component reliability problems were detected. 
» Reliability agreed closely with available field 
Gata. 
»s Failures were due to fabrication technigues, 


design problems and normal component failure. 
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The data gathered during the TAAF program showed that MTBF 
during the first 4000 hours of operation on the four 
machines remained low at about 500 to 600 hours. After 4000 
hours a steady improvement occurred so at the completion of 
testing (12,000 hours) the MTBF was about 1500 hours. The 
results of these formal tests essentially confirmed what had 
been suspected by users a year and a half previously - that 
memory boards and power supplies were a major cause of 
failures, and that a significant "burn-in" period was 
necessary for reliable operation. 

By the end of 1975 many design deficiencies had been 
corrected through Engineering Changes. The contractor had 
also requested waivers on certain deficiencies which he 
thought too rare to warrant attention. ELEX-570 approved 
two of those requests for deviation from the design 
specifications: circuit breaker trip under shock test, and 
Electromagnetic Interference (specifically magnetic 
radiation) test results. All other requests had _ been 
refused, but by the end of 1975 the contractor had failed to 


correct three deficiencies: 


* The NTDS serial I/O interface was experiencing signal 
reflections when cable lengths of 150 to 225 feet 


were used. 


* Under certain conditions the condition code was not 
set properly during double precision subtract 


Operations. 


* Under certain conditions Floating Point Add/Subtract 
Operations resulted in errors. 
As a result, the government stopped accepting production 
units from December 1975 to February 1976. This firm action 
Caused the contractor to submit ECP's to correct the three 
deficiencies. 


Computer serial number 550, which was produced in 
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February 1976, became the base-line for a second retrofit. 
Retrofit II implemented the Engineering Changes to correct 
the three design deficiencies listed above plus six others. 
(About 90 Engineering Change Proposals had been submitted by 
that time.) | 

Naturally, the two shutdowns put UYK-20 production 
behind schedule. At the User's Group meeting in May, 1976 
it was reported that 824 units had been ordered, but only 
637 delivered. 

At the same User's Group meeting ELEX-570 reported the 
establishment of an AN/UYK~-20 Support Software Repository. 
The purpose of the repository was to collect and distribute 
aS reguired to U. S. Government UYK-20 users, software 
developed by other U. S. Government users. This effort was 
designed to reduce software development redundancv and thus 
reduce development costs. Also reported to the User's Group 
was the impending release of a new technical manual, the 
first major revision of this document. 

This chapter has related the growing pains of a computer 
system from development through initial production. Many of 
the problems were to be expected in such a project. The 
unfortunate part of the UYK-20 history was that throughout 
this growth period users were dependent on the computer as a 
component in tactical systems under development. The early 
unreliability of this component compounded the problems 
encountered in developing those systems. The next chapter 
Will discuss the impact of the UYK-~-20 computer on user 


Systems during this period of growth. 
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IV. EVALUATION OF THE SYSTEM 


The previous chapters have been historical in Nature, 
relating the events which marked the development and initial 
production run of the standard minicomputer. [t (1S @iehe 
purpose of this chapter to evaluate the system itself and 
the impact of UYK-20's growing pains on the development of 


those systems which used it as a system component. 


A. COMPARISON OF SPECIFICATION AND FINAL PRODUCT 


Chapter II, Section C and Appendix B discussed the 
Specification upon which the AN/UYK-20 DPS acquisition was 
based. To compiete the historical picture presented in 
previous chapters, it is necessary to briefly discuss the 
actual product which resulted from the standard minicomputer 
acquisition. For ease of comparison, App. H summarizes the 
characteristics of UYK-20 as it existed at mid-year 1976. 
Appendix B summarizes the DRG'S specification. Appendix I 
lists the basic hardware configuration and options 
available. Appendix G describes the system support 
software. References 16 and 17 provide further details. 

By comparing Apps. B and H it can be seen that the 
UYK-20 system met or exceeded the specification in all major 
areas except reliability and maintainability. As discussed 
in the previcus chapter, MIBP to 2000 hours has never been 
demonstrated. No empirical data on MTTR was available. It 
must be remembered that MTTR included localization of the 
problem, correction, aiignment and calibration, and system 
Checkout. It could be postulated that meeting an MTTR of 15 
Minutes presumed that the diagnostic programs were ready to 


load (via magnetic tape or paper tape), that the technician 
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was familiar with the diagnostic procedures published in the 
Technical Manual, and that a complete spares kit was 
available. If the trouble was isolated to a module which 
was missing from the spares kit, the MTTR would necessarily 
include time to procure the part. 

The UYK-20 represented improvement over the 
specification in the areas of speed, number of general 
registers, instruction repertoir, weight and power 
consumption. Weaknesses were in the memory addressing 
scheme and interrupt structure. Some weaknesses in the [I/0 
structure were discussed. in Chapt. II. In addition, the 
Central Processor (CP) and the I/O Controller (I0c) ended up 
sharing the Same memory port, with the IOC having priority 
over the CP. An optional Direct Memory Access (DMA) channel 
was provided, which accessed memory through a second memory 
port. ThisS minimized interference between the CP/IOC and 
the DMA device, but the addition of the DMA capability added 
about 65 nanoseconds to the memory cycle time. An 
additional drawback was that the CP/IOC had priority over 
the DMA in acceSSing any particular memory bank. Since many 
accesses are sequential, . the CP could lock-out the DMA 
device from memory. Although it was not mentioned in the 
documentation, a jumper connection on a PC card could be 
modified to give the cCP/IOC and DMA memory ports equal 
priority. 

There WwaS no provision to expand main memory beyond 
65K-words. 

Although multi-level indirect addressing was possible, 
the procedure for implementation was awkward and involved 
setting indirect control bits in a status register and 
storing information in an Indirect Word. 

Sixty-four page registers existed so that main memory 
could be divided into 64 blocks of 1,024 words each. No 
memory protection existed, however, sahich was necessary to 
prevent inadvertant access to pages in memory by 


unauthorized programs. Also misSing was a provision for a 
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privileged state (i.e. a set of privileged instructions 


) 


which could be reserved for use by a designated executive 
prograa. The lack of those latter two capabilities 
prevented the efficient implementation of program swapping 
algoritha@as for multi-programming applications. The 
usefulness of the page registers was thus limited 

The interrupt structure weakness primarily involved ta 
inability to nest interrupts. Ii an interrupt from one 
class was interrupted by an interrupt from another aigher 
priority class (there were three classes), the lower 
priority interrupt would be saved while the higher priorit 
interrupt was processed. However, only one storage area for 
Saving status registers, program registers ani real-time 


clock existed per interrupt class. If an iaterrupt 


’ 


pre-empted another interrupt of the same class, the sane 


( 


storage area would be reused and the previous program status 
would be lost forever. 

The instruction repertoir was extensive, reflecting tae 
Capabilities of microprogrammed control. Instructions were 
incorporated from the AW/UYK-15(¥) instruction set to Rake 
the UYK-20 upward compatible with that machine. Altho 
mot required by the specification, significant capability 
for floating-point, mathematical and trigonometric fua 
existed in an optional sodule of saicroprocram ro 
designated the MATHPAC. Also available as an option was 512 
words of user specified amicroprocraa 
the Microgrowth. 

By 1976 there was available an extensive set of sSudport 
software [App. G], but it must be remembered that the first 
Systems only had an assembler program. The rest of the 
software was developed over the ensuing three years. 
Significant also was the fact that MTBF was auch wors 
the early months than tn2 1500 hours rm 

This section has briefly compared the AN/UYK-20 DPS with 
the DRG’'s specification. Ia general more capa isted 
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in the final product than was ori 





some important exceptions. Ensuing discussions will compare 
the UYK-20 with the "off-the-shelf" state-of-the-art in 
minicomputer .- design on late-1972/early-1973. The 
discussions will provide further insight into the true 
capabilities of the AN/UYK-20 DPS. 


B. COMPARISON OF AN/UYK-20 DPS WITH THE 1972 
"OFF-THE-SHELF" MINICOMPUTER STATE-OFP-THE-ART 


It has been stated previously that the standard 
minicomputer specification may have been too restrictive. 
If given the funding constraints, the acquisition strategy 
had embodied design-to-cost concepts, for example, so that 
the proposals could work toward the best system for the 
money guided by a performance specification, the finai 
product may have looked much different. It would be 
difficuit to postulate the cost of militarizing any 
particular commercially marketed computer systen. Lt as 
beyond the scope of this thesis to predict what the 
proposals would have been, given the development funds and 
production prices eventually realized. This section will, 
however, discuss the technical possibilities available in 
late-1972 and early-1973. The intent is to consider that 
State-of-art which was through development and into 
production about the time of the standard minicomputer 
Request for Proposals (RFP). The assumption is, as 
previously stated, that the Navy wanted to minimize time and 
development effort and so would look for a system which was 


ready for market. The discussions will also provide a 
further means of evaluating the AN/UYK-20 DPS. For 
information, four Minicomputers representing the 1972 


technology are profiled in Apps. J through 4M. 
1. Architecture 


Certainly the microprogrammed processor was the nost 
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common architecture in 1972 minicomputers. Of the four 
examples, only the Digital Equipment Corporation PDP-11/45 
was not microprogranmmed. Microprogramming permitted a 
reasonably powerful instruction repertoir while minimizing 
size and electrical power consumption. Basically two types 
of microprogramming were used. Horizontal microprogramming 
utilized a long micro-instruction word where each bit 
controlled a specific register-transfer function. The 
Varian 73 with a 64-bit micro-instruction word was a good 
example of that design concept. The Rolm 1602 with a 32-bit 
micro-instruction word was a border line case. Vertical 
Microprogramming utilized shorter micro-instruction words 
which required some hardware decoding in the _ control 
process. The Hewlett Packard 2100A with a 24-bit 
micro-instruction word and the OUYK-20 with a 16-bit 
microinstruction word are examples of vertical 
microprogramming. The tradeoff between the two types was 
more .high-speed memory and simpler hardware Lod re. for 
horizontal versus less memory but more complex logic in the 
case of vertical. A convenient capability in a 
Microprogrammed processor resulted from the use of Writable 
Control Store (WCS) memory in place of Read-Only-Memory 
(ROM). WCS memory allowed the user to alter the 
Microprograms or add his own routines with the same ease 
encountered in storing programs in Random Access Memory 
(RAM). By contrast, many ROM designs involved methods of 
program storage which were unalterable. Some minicomputers 
allowed a mixture of ROM and WCS in the control memory. 
This feature was totally lacking in UYK-20, even in the User 
Microgrowth section, which had to be factory produced. To 
circumvent this problem, FCDSSA San Diego developed a device 
Called GENRAM which plugged into the User Microgrowth module 
Slot of the UYK-20. This device, along with a microcode 
assembler, facilitated development and test of microprogram 
routines for the UYK=-20. 

By contrast, the DEC PDP-11/45 achieved a powerful 


58 





meetruction set through hardware implemented logic. To do 
so DEC sacrificed size and power consumption. By uSing 
high-speed bipolar logic and Large-Scale-Integration, DEC 
achieved much faster instruction execution speeds than 
possible with a microprogrammed architecture. For example, 
an Add instruction required only 0.3 usec contrasted with 
0.75 usec for the same operation in UYK-20 or 1.96 usec in 
HP2100A. 

Another architecture feature available on 
minicomputers in 1972 was register "push-pop" stacks. The 
PDP-11/45 had an extensive stack manipulation capability, 
but it was also available in a more limited way on smaller 
Machines like the Rolm 1602. A "push-pop" stack was a group 
of registers configured so that if a value was stored in the 
top register, all previously stored values were 
automatically "pushed" down to the register "below". If the 
stack was referenced by an instruction, the "top" value 
"popped" off and all values previously stored moved "up". 
Actually the stack was implemented through the use of a 
stack pointer register which always pointed to the "top" 
Memgister on the stack. This was a last-in-first-out sort of 
Operation. Stacks were useful for storing data that would 
be used in a preset order, such as nesting interrupts where 
the last machine state (values of the program counter, 
status registers and other important data) were "oushed" 
mmeo the stack, to be “popped" off when the last interrupt 
finished processing. The UYK-20 had no stack capability. 

Another architecture attribute was useful 
Particularly where programs had to be swapped on and off a 
Mass storage device as ina amulti-programming environment. 
That attribute was a Privileged State. Basically, a set of 
instructions was provided which could only be executed while 
in that special state. Instructions which stopped program 
execution, altered memory assignments of programs, altered 
memory protection, etc. would be part of a privileged 


instruction set. Combined with features like memory protect 
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and paging hardware, the existence of a privileged state 
allowed powerful and efficient program swapping algorithms 
to be implemented. A privileged state was generally found 


only on larger machines like the PDP-11/45. 


2. Main Memory 


Main memory generally was available in-:three types: 
magnetic core, Metal Oxide Semiconductor (MOS) and bipolar 
semiconductor. Core memory ranged in memory cycle speeds 
from 0.6 usec to 1.5 usec while semiconductor nemories 
realized memory cycle speeds down to about 0.3 usec. The 
tradeoff was that semiconductor memories were volatile, 
requiring additional power to refresh the data stored. 
Power failure would result in the loss of all stored data 
unless a backup battery power source was provided. Core 
memories were non-volatile and would retain data for very 
long periods of time. Core memories were generally less 
expensive than semiconductor, although LSI techniques were 
lowering the cost-per-bit of semiconductor memories 
drastically. Many minicomputers, such as the Rolm 1602 and 
the Varian {she offered a mix of memory types. 
Communications with memory were purposely designed to be 
asynchronous (speed independent) to allow future plug-in of 
higher speed memories as they became available. The UYK-20 
utilized core memory only. Memory protection capability and 
memory parity were not incorporated in the UYK-20 for 
reasons discussed in Chapt. II, Sect. cC. Those features 
were available on some minicomputers (HP2100A and Varian 73) 
and almost always incorporated on larger computers like the 
PDP-11/45. Memory parity was usually implemented by the 
addition of two bits per memory word (one parity bit for 
each 8-bit byte). Memory protect in minicomputers could be 
implemented by a single register of one bit per memory block 
Or by one or more boundary registers which would contain the 
address of the upper and/or lower boundary of a protected 


memory block. Most minicomputers offered at least two 
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memory ports (i.e. channels) through which to access memory. 
The most common arrangement was for the CP to access memory 
through one port and a DMA channel through another port. 
Both the CP and the device on the DMA channel could access 
memory at memory cycle speeds. HP2100A featured three ports 
(two DMA channels plus CP). Access speeds of 1,000K-words 
per second were typical. 

A feature within the minicomputer state-of-the-art, 
but not often implemented, was interleaved memory. This 
memory addressing scheme placed consecutive addresses in 
different memory banks to eliminate one device locking out a 
particular memory bank with a large number of consecutive 
address accesses. PDP-11/45 featured interleaved memory as 
an option. 

The PDP=11 family of computers featured a unique 
architecture attribute. DEC connected ail functional 
devices (CP, memory banks, I/O channels, DMA channels) to a 
Single data/address bus called a UNIBUS. Each functional 
device was independent and could access any other device on 
the UNIBUS independently. In the PDP-11/45 every general 
register, memory location and I/O register was given equal 
Status as a location with an address. Signals to and from 
all devices were multiplexed on the UNIBUS. PDP-11/45 
realized data rates up to 2,500K-words per second with that 


scheme. 
3. Instruction Set 


As previously discussed, the size of the instruction 
Set was highly dependent on architecture. Microprogrammed 
Minicomputers featured far more powerful instruction sets 
than purely hardware implemented architectures. Most 
Minicomputers offered single and double-word manipulation. 
The HP2100A, PDP-11/45 and UYK-20 featured floating-point 


lnstructions as an option. UYK-20 floating-point 
lastruction speeds were medium compared to other 
Minicomputers. For example, for a floating-point Add 
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instruction the times were HP2100A: 23.5 usec to 59.8 usec; 
UYK-20: 7.7 usec to 17.4 usec; PDP-11/45: 2.4 usec to 5.5 
usec. 

Bit manipulation capability was extensive on those 
minicomputers designed for process control. For instance, 
the Texas Instruments CP-960A was a bit oriented, rather 
than a word oriented, machine. Some general purpose 
minicomputers like the HP2100A and PDP-11/45 offered several 
bit manipulation instructions (Test and Set, Compare, Reset, 
etc.). UYK-20 featured those basic bit manipulation 
functions except Test and Set which required two 
instructions ~ very awkward in a real-time programming 
environment. Byte manipulation was a necessary capability 
for real-time processing, expecially for data communications 
applications. UYK-20 possessed some capability (Load, Load 
and Index, Store, Add, Subtract, Compare, Compare and 
Index). The use of those byte manipulation instructions was 
necessarily awkward since the UYK-20 was a word oriented 
rather than a byte oriented machine. That is, each 
consecutive address referenced a full word. inie was 
necessary to indicate by setting a bit in a register which 
of the two bytes in the word addressed was desired. Byte 
Manipulation instructions were not, however, a common 
feature of commercial general-purpose minicomputers. 

Another feature not commonly found on minicomputers 
WwaS the implementation of trigonometric and hyperbolic 
functions as machine instructions. Through MATHPAC a useful 
set of such functions was available on UYK-20 as an option. 
Some available microprogrammed machines featured extra 
control storage capacity where users could implement such 
functions. 

A capability available on some minicomputers, but 
totally lacking on UYK-20, was mnemory-to-memory 
instructions. That is, the capability to perform operations 
On data in memory and return the result to memory without 


first loading the data into a register. Varian 73 and 
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PDP-11/45 both featured some memory-to-memory capability, 
but in UYK-20 all data had to be first loaded into a 


register to perform further operations. 


4. Input/Output 


The most popular I/O scheme in 1972 minicomputers 
featured a single I/O bus. Ina single I/O bus’) structured 
machine, data transfer was generally controlled by the CP. 
Data rates were slow (300K- to 400K-words per second). 
Generally a number of peripherals could be interfaced on the 
I/O bus. The Rolm 1602 could support up to 61 devices, but 
the HP2100A only 14.. Varian 73 was also a single I/O bus 
structured machine. Such machines usually featured at least 
one DMA channel. The Varian 73 featured a Priority Memory 
Access (PMA) channel which allowed data transfers up to 
3,300K-words per second when semiconductor memory as 
installed. A typical DMA channel data rate was 1,000K-words 
per second. 

The processor independent IOC featured on the UYK-20 
made that I/0 scheme more powerful than found on nost 
Minicomputers. The I0C acted as an independent processor 
With its own control memory and instruction set. Each group 
of four channels contained itS own arithmetic unit and 
registers and so could operate independently once data 
transfer was initiated by the I0C. One drawback was that 
the IOC shared a memory port with the CP. Another was that 
four channels shared an arithmetic unit and registers so 
that all channels of one group had to be of the same type. 
The instruction set implemented in the IOC was minimal. 
Data manipulation had to be performed by the CP. 

Again, the PDP-11/45 UNIBUS structure was a unique 
approach. Each peripheral device was interfaced to the bus 
through its own independent controller. Thus, every I/0 
Channel was a DMA channel. In addition, each device could 
communicate independently with another device. Every device 


On the UNIBUS, including the CP, was assigned a priority. 
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Communications were handled according to priority by a 
UNIBUS Priority Arbitration Unit. By that systen, I/0 
transfers were handled indentically to memory accesses. 
Thus, every instruction implemented on the PDP-11/45 could 


be used in an I/O program to manipulate data. 


5. Interrupt Structure 





Some 1972 minicomputers featured a priority 
interrupt Structure. AS previously discussed, minicomputers 
with stack architecture generally featured multi-level 
interrupt nesting capability. On other machines nesting was 
accomplished by providing storage area for machine status 
for each interrupt line. Two methods of handling interrupts 
were common. The first involved branching to a _ specific 
memory word assigned to the interrupt, which contained the 
address of the interrupt service routine. The second 
allowed a direct branch to the interrupt service routine. 
The latter method was faster, but required more hardware 
logic. UYK-20 implemented the former scheme. 

On UYK-20, as previously discussed, only three 
storage areas were provided to store machine status (one per 
interrupt class) so that nesting capability was severely 
limited. 


6. Construction 
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The term "modular construction" had different 
connotations with different manufacturers. The most common 
scheme featured a simple backpanel which provided only power 
lines, data and address buses, etc., which were common to 
all printed circuit (PC) card modules. All PC cards were 
the same size and could be plugged into any slot. Ci ecules 
Oh a particular PC card related to functional catagories, 
there being one PC card for the CP, one for memory control 
Circuits, one for each memory bank, and one for each I/0 
device interface. HP2100A, Rolm 1602 and Varian 73 were 


configured in that manner. The PDP-11/45 also was Similarly 
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configured, although backpanel wiring was more complex due 
to the UNIBUS structure. PC cards were generally large and 
were structurally reinforced for strength. 

UYK-20 featured an entirely different approach. PC 
card modules were utilized, but cards were small and were 
hardware type oriented rather than functionally oriented. 
For instance, control memory and associated circuitry 
accupied four PC cards, the master clock occupied another, 
interrupt storage another, and each general register set 
(two sets of 16 registers each) occupied a card. The UYK-20 
scheme facilitated the installation of plug-in options that 
were available [App. I], but created a complicated wiring 
Situation on the backpanel and greatly increased the number 
of different types of PC cards utilized. The maintenance 
plan where a majority of the PC cards were "throw-away" 
modules (i.e. those cards could be discarded when found to 
be defective) also depended on that scheme. Naturally, a PC 
card containing an entire processor would be too expensive 
to discard. The repairable PC cards in the JUYK-20 were 
those few that were large and functionally oriented - Memory 
Array Boards, Memory Control Boards and I/O Interface cards. 
Those generally were inadequately reinforced, tended to 
bend, and were extremely difficult to remove and install. 
Interestingly, the Rolm 1602 featured large functionally 
Oriented cards and met all military specification 
requirements including shock and vibration testing. That 
computer was service approved and designated AN/UYK-19(V). 

A significant achievement by Rolm in the 1602 design 
was a demonstrated MTBF of 11,000 hours. Since the UYK-20 
experienced significant reliability problems, it would be 
informative to investigate the differences in those two 
computers. it 1s beyond the scope of this thesis to present 
a detailed analysis of the impact of the design and 
construction of the two machines on their demonstrated 
reliability. Some major points can be made, however. The 


logic design itself was a, CONRCEIDUTOG to UYK=Z0"s 
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reliability problems. For example, the TAAF program 
conducted at Naval Weapons Center Dahlgren revealed that the 
master clock and certain logic gates in the UYK-20 were 
overloaded. A user reported that the MIL-STD-188C 
‘asynchronous, serial I/O interface card was defective in 
that the channel would interrupt on both leading and 
trailing edges of an interrupt signal pulse. Those were 
basic logic design problems and would directly contribute to 
module failures. Construction and reinforcement of larger 
PC cards waS inadequate in UYK-20. With freguent handling 
such cards suffered broken components, jumper wires, printed 
circuit runs and connection pins. All such occurrences 
created circuit failures which lowered MTBF. In a complex 
backpanel wiring Situation, lack of adeguate quality 
assurance measures could allow wiring errors to pass 
unnoticed. Such errors could appear as circuit failures 
under troubleshooting procedures We be Zang diagnostic 
software. Over the three years after contract award, UNIVAC 
had corrected many of those sorts of problems. Yet the MTBF 
had risen to only 1500 hours. The reason for that may lie 
in the selection and integration of components. The ability 
for a manufacturer to control the quality of components used | 
in producing computers would directly impact on reliability. 
In producing the 1602, Rolm Corporation had that control. 
Most components in UYK-20 were procured under military 
specifications (with the exception of integrated circuits). 
Such components must be procured from a Qualified Parts List 
(QPL) vendor under military specification control. In that 
Situation UNIVAC had no control over component quality. 
Hardware engineers interviewed generally agreed that many 
components procured under military specifications probably 


exhibited MTBF's in the hundreds of hours. 
7. Support Software 


It is beyond the scope of this thesis to present a 


detailed analysis of the available minicomputer support 
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software an Waa 2e Some comments can be made about 
availability, however. As indicated in Apps. J through 4M, 
commercial minicomputers generally featured a complete set 
of software. In most caseS a minicomputer was upward 
compatible with earlier models, so that each inherited a 
package of well tested and fully documented Support 
software. New software modules could be added at leisure to 
take advantage of the added capabilities of the more 
advanced machine. 

Most software engineers interviewed agreed that 
adequate operational testing was difficult to achieve. 
Complete debug of a software module depended on extensive 
use in the field. Naturally, any software package inherited 
from a market-tested computer had that advantage. 

The -UYK-20 computer did not have that advantage. 
Aithough upward compatible with the AN/UYK-15(V) [App. Dj], 
that machine did not possess a complete package of support 
software and had not had extensive use. Support software 
for UYK-20 was developed during the three years following 
contract award. As of mid-1976 the CMS-2M compiler and 
SDEX-20 real-time executive were still in the "user debug" 
stage. All software was still receiving enhancements to 
upgrade capability as funds became available. 

The foregoing material in this thesis has discussed 
the events which occurred in the AN/UYK-20 DPS acquisition 
history and the technical advantages and drawbacks of the 
syste. The final section in this chapter will discuss the 
impact of those events, advantages and disadvantages on the 


users and their tactical system development efforts. 


©. IMPACT OF AN/UYK-20 DPS ON DEVELOPMENT OF USER SYSTESS 
The events of the three years after contract award, 


which have been referred to a "growing pains", hada 


Significant impact on the efforts of users to develop 
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tactical systems utilizing UYK-20 as a system component. 
This section will discuss the various ways which that systen 
component aided or complicated those development efforts 
during the period mid-1973 to mid-1976. 


1. Establishment of AN/UYK 


The implications of establishing a "standard" system 
component were discussed in Chapt. II, Sect. B. For those 
programs well into development with another minicomputer and 
for programming language, the impact on acquisition cost and 
schedule to switch to UYK-20 was significant. One project 
reported a two year schedule slip and software costs of 
$350,000 to $400,000 to reprogram for the UYK-20. Since 
that system involved primarily data-handling, only limited 
processing power and core memory capacity were needed. A 
lower cost processor with 4K-words of memory and unit cost 
of $15,000 was replaced by a minimum configuration JUYKk-20 
with 8K-words of memory and unit cost of $24,000. Another 
project reported a four to five month slip and $400,000 to 
$500,000 cost to reprogram with CHS-2M, the standard 
high-level language. 

The trade-off for those projects was to lower 
life-cycle costs through savings in ILS costs, training 
costs, etc. as previously discussed. Unfortunately, the 
immediate concern was alwayS initial acquisition cost, 
schedule, and performance. While life-cycle cost was given 
lip-service, a project's success was ultimately measured by 
success in those three areas. Thus, imposition of the 
Standard on a system well into development impacted directly 
on the measure of the project's success. 

Because of the necessity co identify firm 
requirements for UYK=-20 production units, and to obtain O&SMN 
funds through the surcharge scheme, NAVELEX was forced to 
require those projects to switch to UYK-20. 

The technical drawback of adopting a standard was 
that the UYK-20 might not be specifically suited for a 
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particular application. An example might be an engine 
monitoring and control System where a powerful bit 
manipulation capability was needed. That project would be 
reguired to use UYK-20 regardless of the minimal bit 
manipulation capability. Interestingly, no project 
personnei found the UYK-20 totally unsuited for their 
application. It has been reported that as of mid-1976 over 
100 projects were utilizing UYK-20. Tasks included the 


following diverse sorts of requirements: 


* Message Processing Systems 
s Low memory capacity (8K- to 16K-words) 
e Low computing power 
s High I/O capacity (12 to 16 channels) 
e High data rates 


* Navigational Systems 

«e Medium memory capacity (16K- to 32K-words) 

a 32-bit (double word) I/O transfer 

s 32-bit data manipulation 

s Floating-point trigonometric and hyperbolic 
functions 

e High accuracy (up to 24-bits per data word 
preferred) 


s Low I/O capacity (4 to 8 channels) 


* Signal Analysis Systems 

s Large storage capacity (65K-words of memory plus 
high-speed mass storage device (disk) on DMA 
channel 

s Multi-programming capability 

e Powerful mathematical capability 

»s High throughput (instruction execution rate) 

s High I/O data rates 

e High I/O capacity (8 to 16 channels) 


* Target Tracking and Fire Control Systems 


a 32K- to 65K-words of storage capacity 
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a 12 to 16 I/O channels 

a Mass storage device (disk) on DMA channel 

a Floating-point and trigonometric functions 

a High throughput (instruction execution rate) 

a Special user functions implemented through 


Microgrowth 


It was a Significant accomplishment, and spoke well for the 
DRG specification, that UYK-20 was able to handle those and 
many other diverse tasks. 

The conclusion was that few projects were severely 
impacted by imposition of a standard minicomputer. 
Unfortunately, that statement could not be made about 
UYK-20, the computer that became the standard. 


Je Hardware/Pirmware Capabilities 


Users generally found the UYK-20 architecture 
powerful enough for their needs. Local Jumps, Load Multiple 
and Store Multiple instructions not common on minicomputers 
were very useful. The availability of 32 general registers 
Was a powerful programming aid. I/0 structure was versatile 
and powerful with the processor independent f[I0C. Certain 
attributes caused some inconvenience, however. 

The awkward byte addressing scheme discussed in the 
previous section would add an additional instruction to byte 
Manipulation operations in order to set the upper/lower byte 
indicator. Execution time for the byte operation would be 
increased about 50% and program storage requirements 
doubled. One solution was to write self-modifying code, to 
modify the byte manipulation instructions "on-the-fly". 
This created programs which were very hard to debug. Also, 
Such code was non-reentrant; i.e. it could not be reused 
Without reloading the original program from an external 
device, and it could not be shared in a multi-programming 
environment. 


Lack of memory-to-memory instructions added Load and 
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Store instructions to those operations because of the need 
to put the data in registers. About 1.5 usec was added to 
the execution time for memory-to-memory operations, and 
program storage requirements were tripled. Lack of a Test 
and Set instruction (that operation reguired two 
instructions in UYK-20) could cause major problems. If an 
interrupt occurred between the two instructions, which 
changed the value that was being tested, then the test 
already performed was invalid. The routine executing the 
Test and Set instructions would not be aware of the change 
and would proceed on the basis of the original test results 
when the interrupt finished processing. The solution was to 
lockout interrupts before executing the Test and Set 
instructions and to restore interrupts after completing the 
Test and Set. That solution added two to four instructions 
and 3.3 to 4.8 usec to a Test and Set operation. 

There were no absolute compare instructions in 
UYK-20. When comparing two words, the most significant bit 
would always be considered the sign. T0 compare a 16-bit 
absolute word a double-word operation was needed. Time and 
Storage requirements were thus again added to the user 
progran. 

The Sum total of those sorts of deficiencies 
Significantly decreased throughput and increased storage 
requirements. The solution was to implement the missing 
Capabilities in the User Microgrowth area of control memory. 
Such a development effort had to be user funded, however. 
AS an example, one activity received a quotation of 450,000 


to implement four instructions in Microgrowth: 
* Increment and Store Memory 
* Literal Add to Memory 
* Add to Memory 


* Literal Store to Memory 
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In addition, an extra $1,000 was added to the price of each 
MEeoduction unit. Many projects preferred to suffer the 
inconvenience rather than pay the price. 

For those systems with large storage requirements 
and a large number of tasks which could be performed 
Simultaneously, the lack of proper tools to implement 
multi-programming waS a serious drawback. Although page 
registers existed, there was no privileged instructions or 
memory protection with which to implement sophisticated page 
swapping algorithms. The alternatives reguired more time 
and tied up valuable storage space, both expensive 
commodities in time-critical, real-time applications. 

The storage capacity problem could have been 
relieved in some cases if a provision to expand memory 
beyond 65K-words had existed. Alternatives involved adding 
additional UYK-20's to the system, which waS expensive if 
the additional processing power was not also needed, or 
adding a mass storage device on the DMA channel, which would 
often not meet speed requirements. To solve the dilemma in 
one case, a semiconductor memory disk emulator Was conceived 
Which would interface to the computer through the DMA 
Channel. Ability to utilize semiconductor memory in place 
of core memory would have alleviated some similar problems 
1f that capability had existed. 

A capacity problem also plagued some projects in the 
I/O area. Although the processor independent I0C provided 
powerful I/0 capabilities, only 16 channels were available, 
With the type configuration constraints previously 
discussed. To get more capacity required multiplexing on a 
Channel, which slowed down th data rate, or adding more 
UYK-20's to the systen. 

Certain I/O configurations would have benefited from 
complete independence of the two sides of a duplex channel. 
However, both sides shared registers and could not be 
Cleared independently. Several users stated the need to 


wlite extra routines to prevent losing data on one side if 
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the need arose to clear the other side of a channel. 

A characteristic of serial, synchronous interface 
channels was that the first few characters transmitted were 
"garbage" due to the need to establish synchronization. 
This Situation could not be tolerated on a radio (RF) data 
channel where good data would be lost. The solution was to 
alter the RF Data Channel hardware. 

A common complaint from development programmers was 
the inadeguacy of the Maintenance Panel for software 
debugging. Lack of I/O status indicators and 
multiple-register displays were cited as drawbacks. The 
Maintenance panel had too much capability for hardware 
troubleshooting, but not enough for program debug. A 
solution would have been to reduce the capability of the 
Maintenance panel and provide a plug-in software debug 
panel. The lack of I/O status indicators was a serious 
problem since, with the IOC independent of the processor, 
there was no way to determine if an [I/O transfer was 
actually taking place after it was initiated. 

Lack of interrupt nesting capability was a major 
concern to development programmers. Care had to be 
exercised so that multiple interrupts occuring in one class 
would not store over the original machine status, thus 
preventing a return to the interrupted routine. The 
solution was usually to lock-out other interrupts, which 
Virtually nullified the priority interrupt capability. 
Real-time programs were generaily interrupt driven, thus, 
loss of priority interrupt capability was a serious 
drawback. 

fhe awkwardness of using the indirect addressing 
Capability caused some programmers to abandon its use in 


favor of direct addressing with indexing. 
3. Availability of Support Software 


== a) ae eS See eee ep ee SS 


The support software for the AN/UYK-20 DPS was’ slow 


mi Cconing. Those programs in development in late-1973, 
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which were forced to switch to UYK-20, had only a Ilimited 
capability assembler. As a result, many created their own 
program development capability. Doing that added to the 
time and cost of a system since operational program 
development would cease while programmers wrote monitors, 
assemblers, editors, debug routines, etc. AS an example, 
the cost of developing an assembler was $5,000 to $100,000 
depending on its capability. It was cheaper and faster to 
write your own, however, than to wait for the Level I and 
Level II systems to be released and debugged. 

The late delivery of CMS-2M (early-1975) caused 
two-fold problens. Many early operational programs for 
UYK-20 had to be written in assembly language. Since it 
took the same time for a programmer to code one line of 
assembly lancquage aS to code one line of a high-level 
language (with a ratio of about six assembly language 
instructions to one high-level language instruction), the 
cost was Significant. Those projects which elected to start 
development with another high-level language (usually 
FORTRAN) faced the prospect of reprogramming in CMS-2M when 
that compiler became available. 

The whole question of program development facilities 
for a ninicomputer 1s worth some discussion. It was 
generally not possible to configure a small computer for 
efficient program development. Level II Operating Systen, 
Which was self-hosted on the UYK-20, could support only one 
programmer at a time. Although both interactive and batch 
modes were provided, compile times were slow and debug 
facilities were minimal. What was generally needed was a 
larger computer with a time-sharing monitor so that several 
programmers could work Simultaneously. An ideal system 
would feature cross-assemblers and compilers to generate 
object code for the small computer. Adequate memory, disk 
storage and a number of program development aids such as a 
text editor, debug utilities, data conversion routines, etc. 


would be a necessity. A program to emulate the small 
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computer would be useful for Pili La a depugging of 
operational software. 

A few activities which were to do extensive program 
development for the UYK-20 did create such systems. The 
Electromagnetic Systems Laboratory in Sunnyvale set up a 
time-sharing system on a Hewlett Packard 3000 computer. The 
system featured a direct link to a UYK-20 computer via a 
special intercomputer I/0 channel. Source code generated on 
the HP3000 could be loaded directly into the UYK-20 for 
assembly or compiling. The Autonetics Division of North 
American Rockwell set up a similar system based on a 
PDP-11/45 computer. FCDSSA San Diego developed the 
_CMS-2Y(20) compiler for use on an AN/UYK-7 computer under 
the SHARE/7 time-sharing system aS an aid to their software 
development and maintenance efforts. 

Such systems were understandably costly to set up. 
In addition, the hardware and asSociated software to 
interface the system directly to a UYK-20 had to be 
developed in-house. The project sponsoring the development 
had to provide the funds. The dilemma facing the project 
Manager was whether it was more cost effective to fund a 
program development facility or to provide a self-hosted 
System for the UYK-20 and suffer the inefficiencies. AS an 
example, the price of a self-hosted system with Level II and 
CMS-2M would be about $150,000 including peripherals. At 
the other end of the price spectrum, the UYK-7 hosted system 
would cost about $800,000. Commercial systems would be 
priced in between depending on capability. 

To provide program development facilities and _ save 
projects the cost of support software and peripherals, a 
System Design Laboratory (SDL) was conceived by the Naval 
Electronics Laboratory Center. That was a commercial 
computer based time-sharing system with cross-assemblers, 
compilers and an emulator for UYK-20. The system could be 
accessed via the ARPANET, a commercial nationwid2 computer 


network linked by leased telephone lines. Anticipated 
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drawbacks of that scheme were possible demand beyond the 
system capacity, and the fact that classified programs could 
not be developed on the system. In fact, the majority of 
projects depended on the self-hosted system. The 
non-availability of a well-tested, complete, self-hosted 
program development systen at the outset impacted 
Significantly on both cost and schedule of projects. 


4. Support Software Capabilities 


It is beyond the scope of this thesis to present a 
detailed analysis of the impact of support software 
capabilities on program development. However, certain 
points brought out by development programmers are worth some 
discussion. 

A dynamic debug capability was needed under Level 
II. As of mid-1976 the development of this capability was 
planned, but funds were not available. Dynamic debug 
Capability would allow programmers to perform analysis on an 
executing program without interfering with its execution. 

CMS-2M listings of source code and object code were 
not produced side-by-side, making cross-referencing awkward 
and time consuming. 

CMS-~2M depended on the trigonometric and hyperbolic 
functions provided through MATHPAC. Accuracy provided was 
insufficient in some applications. The large variety of 
useful functions and routines developed for a weli-used 
language like FORTRAN were not available with CMS-2M. 
Because that language anticipated restricted usage, such a 
library of routines would never be created, forcing the 
development programmer to write his own routines = when 
needed. In recognition of this problem, the User's Group 
Software Directory and the Software Repository mentioned in 
Chapter III were an attempt to prevent redundant development 
Of such routines. 

CMS-2M was not an optimizing compiler. Because many 


Operational programs are time-critical and have large 
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storage requirements, it would have been useful to have an 
optimizing version of the CMS~2M compiler to minimize use of 
those assets. 

Like any general purpose real-time executive, 
SDEX-20 reguired too much core and system overhead (time 
spent in executing the executive software) to be widely 
useful. Those applications with time-critical routines and 
large storage requirements were forced to write their own 
real-time mecnitors. By writing an executive in-house it 
could be optimized for the particular application, thus 
minimizing storage and overhead. Many programmers felt that 
a general purpose real-time executive would be useful if the 
source code were available to programmers as a reference to 
aid in writing their own. The low usage. of SDEX-20 raised 
the question of the cost-effectiveness of supplying that 


type of support software. 


5. Availability of Peripherals 


The peripherals problem is actually divided into two 
catagories: peripherals for program development, and 
peripherals for tactical systems. Up to mid-1976 no 
Standard militarized peripherals were available for 
purchase, except Keyboard/printers and paper tape 
reader/fpunches which had been in existance for several 
years. Those units were generally too large EOE a 
Minicomputer installation. Even with the introduction of 
the Alphanumeric Display Device (ADD) and the Cartridge 
Magnetic Tape Unit (CMTU) in mid-1976, important peripherals 
were still dlacking, such as a magnetic tape unit 
(reel-to-reel), a disk storage device, and a graphics 
display terminal. Projects were forced to fund 
Militarizaion of their own peripherals, which created the 
Same sort of proliferation problen encountered with 
minicomputers in the early 1970's. 

During the early production period in late-1973, 
only UNIVAC peripherals could be interfaced with the JYK-20 
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for program development. Those peripherals were generally 
too large and expensive for a minicomputer system, so 
projects began acquiring their own. Costs of procuring 
peripherals included development of device software modules 
to interface with the UYK-20 operating systems. The 
acquisition of peripherals to be used for progran 
development was costly, especially since those peripherals 
would in general not be used in the tactical system itself. 
Projects were wise to retain a UYK-20 system with 
peripherals configured for program development to be 
provided as Government Furnished Equipment (GFE) for future 


development efforts. 


6. Hardware and software Redes oe ey, and 
Maintainability 


The acute quality and reliability problemas 
experienced in the AN/UYK-20 DPS were reported in Chapter 
III. It was those problems that had the most profound 
impact on user development efforts. 

The programs developing in mid-to-late-1973 were 
forced to use Functional Demonstration Models (FDM‘'s) and 
Advanced Production Engineering Models (APE's) in order to 
meet development scheduies. That hardware was essentially 
not ready for release. The numerous deficiencies and 
failures caused significant down time. Projects were forced 
to purchase two computers and cannabilize one to keep the 
Other running. Early production units had Similar problems. 
Software debugging on faulty hardware was a difficult and 
time-consuming task. One activity reported expending three 
Man-months of labor trying to debug a program when the 
problem was actually in the interrupt hardware. 

Efforts to troubleshoot faulty hardware were 
hampered by faulty spares in the spare parts kits. The kits 
were expensive ($13,000 each) so that project managers were 
unWilling to purchase sufficient numbers. Project personnel 


estimated that one spares kit per computer was necessary to 
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ensure parts availability. Memory Array Boards, which 
experienced very high failure rates, were repairable modules 
and were not included in the spares kits. Since the time to 
ship the repairable modules back to UNIVAC for repair and 
return was running six to eight weeks, activities were 
forced to purchase extra Memory Array Boards (at $1,300 
each) to minimize down time. 

It was more timely and cost effective for some 
activities, like NESEC San Diego, to do their own hardware 
trouble-shooting and repair, rather than call in UNIVAC 
engineers. The diagnostic software and documentation was 
not well suited to this effort. The diagnostic routines 
could isolate circuit board failures, but not design 
problems which plagued the earlier machines. Activities 
turned to logic circuit diagrams, but found that those also 
contained errors. It was difficult to maintain accurate 
up-to-date files of logic circuit diagrams since no formal 
system existed for procuring then. . 

Early releases of the support software had many 
errors. User activities attempting to debug the software 
were hampered by inadequate and erroneous documentation. 
Source code was not available initially to aid in their 
merorts. After repeated demands the source code for the 
operating systems was made available, but code for the 
compilers was withheld as a matter of proprietary 
information. Most software engineers interviewed expressed 
the opinion that the support software source code, including 
compilers, should be purchased outright by the Navy so that 
it could be made available to users. That was especially 
true when the support software contained so many errors and 
the documentation was inadequate. In many caseS programmers 
had to resort to the source code to determine the details of 
system software operation. One activity reported that it 
Was once forced to reprogram to take advantage of an 
assembler capability Which was not mentioned in the 


documentation. A basic problem with software documentation 
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was that no detailed discussions of software philosophy were 
presented. Adding the problems in the software on top of 
problems in the hardware made an extremely difficult 


situation for programmers attempting to debug operational 


software. 
7. Lack of Dedicated Appropriated Funds to Support the 
AN/UYK-20 DPS 


It is significant that a majority of problems’ were 
corrected when usage was sufficient to isolate those 
problems. Given time the support software became available. 
Given time the standard peripherals would be available. If 
NAVELEX could have waited until the system was adequately 
tested before release, much of the inconvenience caused to 
users would have been eliminated. The reason that NAVELEX 
could not wait was lack of funding. It was necessary to 
identify specific requirements for production units and _ to 
receive orders for the system in order to get the surcharge 
that paid for project support. NAVELEX was thus forced to 
require the use of the system before it was ready. An 
Obvious solution wasS to wait until funding for the entire 
acquisition cycle was reasonably assured (another year at 
best). Then wait until the system was complete, including 
software and testing, before releasing it (another two to 
three years). Of course, a three to four year delay would 


have brought proliferation of minicomputer types in the Navy 


inventory to an unacceptable level. Some of that delay 
might have been saved by purchasing a "market-tested" 
computer system, then militarizing it. At least the 


reliable commercial equivalent would have been available for 
use in development until the militarized version was 
available. Certainly computer systems existed which could 
meet Navy performance requirements. 

The lack of dedicated funds has thus been identified 
aS the prime-mover in many events in the history of the 


AN/UYK-20 DPS acquisition. The final chapter will summarize 
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and present some recommendations which might prove useful in 


future tactical processor acquisitions. 


81 





V. SUMMARY, CONCLUSIONS AND RECOMMENDATIONS 


In 1972, when proliferation of minicomputer types in the 
Navy inventory was perceived to be a significant problen, 
the Tactical Digital Systems Office (TADSO) of the Naval 
Material Command (NAVMAT) conceived the procurement of a 
standard minicomputer. Use of that minicomputer was 
required in all tactical systems requiring a small computer 
unless sufficient justification was given to use a different 
‘computer. 

Although no funds had been appropriated for such a 
procurement, NAVMAT, with the approval of the Chief of Naval 
Operations (CNO), proceeded to initiate the procurement 
action by reprogramming a minimum of Research, Development, 
Test and Evaluation Navy (RDT&EN) appropriated funds from 
anticipated user projects. A DeSign Review Group (D&G) was 
convened, and a fairly restrictive technical specification 
was drawn up. With the exception of an assembler, support 
software requirements were misSing entirely from the 
specification. At that point the Navy was procuring 
one-half of a minicomputer system with no funds appropriated 
Bor future support. The necessity to get support funds 
Forced NAVMAT to require projects still in their development 
phase to include the standard minicomputer immediately in 
their program and to assesS a surcharge on purchases of 
Standard minicomputer hardware and software. 

The contract award went to the lowest bidder, UNIVAC 
Defense Systems Division of Sperry-Rand Corporation. The 
DRG specification appeared to be influenced by the OUNIVAC 
design philosophy, owing to the large number of UNIVAC 
computers in the Navy inventory. 

Although the original acquisition strategy intended that 


the minicomputer system be a militarized off-the-shelf 
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commercial system, UNIVAC won the competition with a new 
design that had never been in production and was not upward 
compatible with any well-established family of computers. 

In order to meet user project development schedules, the 
first Functional Development Models (FDM) (non-militarized 
prototypes) were delivered within 120 days after contract 
award and the first Advanced Production Engineering Models 
(APE) (militarized prototypes) within nine months after 
contract award. Although the hardware design held the 
potential for good capabilities in a minicomputer, the 
FDM's, APE's and early production units were inadequately 
tested and debugged. Reliability was very low and 
maintainability suffered from inadequate diagnostic 
programs, poor documentation, faulty spares, and excessive 
turnaround time on repairable modules. 

Initially software was non-existent; when released it 
waS inadequately tested and debugged. User efforts to use 
the software were hampered by poor documentation. 

Thus, lack of dedicated funding forced users to utilize 
the standard minicomputer as a system component before it 
was ready. The result was significant labor costs to cope 
with the problems and increased risks in the development of 
Operational programs. 

It was mid-1976, three years after contract award, 
before the system was sufficiently reliable and possessed 
adequate support software to be considered a viable system 
component in a developing tactical systen. | 

It must be recognized that follow-on standard tactical 
digital processors may not be minicomputers. Perhaps the 
design will be a distributed microprocessor system or some 
architecture not yet conceived. The rapid advance in the 
state-of-the-art of digital processors makes the 
possibilities endless. The events connected with the 
Standard minicomputer acquisition do foster, however, some 
conclusions and recommendations pertinent to future 


acquisitions of tactical digital processors, regardless of 
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architectural philosophy. 


1. The life-cycle cost and logistics Support. 
considerations make adoption of standards necessary. 


2. The decision as to how often to reprocure a standard 
involves a tradeoff -between two alternatives: ~—(1) 
reprocuring rapidly enough to keep up with advances in the 
state-of-the-art, and (2) producing a particular standard 
long enough to maximize the economic benefit of large-scale 
production. The tolerance of tactical system development 
engineers for using an "old" standard must also be _ taken 
into account. That decision must be made on the basis of 
factors such as availability of funds and how well the 


current standard is performing at the time. 


BD. The primary goal of the standard minicomputer 
acquisition strategy was to stem the proliferation of 
Minicomputer types in the Navy inventory. That goal was 
accomplished at the expense of significant adverse impact on 
the costs and schedule of user projects. fe Siseenas 
author's opinion that the "cost" of the adverse impact 
outweighed -the benefit of minimizing proliferation. [It 
should be the primary goal of future tactical digital 
processor acquisitions to deliver a highly reliable systen 
complete with support software and accurate documentation. 
That would be simply applying current systems engineering 


management and Integrated Logistics Support policies. 


4, The standard minicomputer procurement was totally 
dependent on user projects for both development and 
Operational support funding. That fact was the underlying 
reason why projects were forced to use the system before it 
Was ready, accounting for most of the events which impacted 
adversely on those user projects. The availability of both 
RDT&EN and O&MN funding for a standard tactical digital 
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processor acquisition should be reasonably assured prior to 
contract award. Based on experience with the standard 
minicomputer acquisition, contract award should be planned 
for two to three years prior to reguired delivery of tke 


militarized version to the fleet. 


Die Since it would be desirable to minimize the time 
between contract award and delivery to the fleet, the 
acquisition strategy should strongly consider procurement of 
an off-the-shelf, market-tested system which exhibits a 
strong heritage from a successful family of processors. 
Availability of software should be a major consideration. 
It is this author's opinion that the strong competition in 
the digital equipment industry assures that new commercial 
systems push the state-of-the-art while at the same time 
exhibiting reliable hardware and software performance. The 
strategy just suggested should thus suffer minimal risk of 
early obsolescence. This strategy would also insure the 


immediate availability of FDM's for use in development. 


6. Award of contract in the standard minicomputer 
procurement was based on two factors, (1) technical 
responsiveness and (2) lowest price proposal. Such a 


strategy precludes consideration of which proposal presents 
the best reliability and performance for the price. Future 
acquisition strategies should require a fully negotiated 
procurement based on a performance specification. Such a 
Strategy would give the Source Selection Evaluation Board 
the flexibility to consider both design and _ price. 
Proposals offering market-tested systems could be weighted 
heavily Since such systemS have uSage data to prove 


reliability and performance. 
a. Despite the fact that a pre-award survey found all 


companies submitting proposals to be responsive, the winner 


experienced immediate and severe quality assurance problens. 
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Those QA problems had a profound impact on user development 
efforts. Future pre-award surveys should firmly establish 
the potential contractors! abilities to produce a reliable 
product. Careful evaluation of quality control standards 
should be made to assure that those standards will insure 


delivery of a reliable product. 


8. The Requirements, Indefinite Delivery contract awarded 
in the standard minicomputer acquisition was well-suited as 
a production contract and should be utilized in future 


procurements of standard equipment. 


Dis The imposition of Military specifications on a 
commercial deSign creates some risk in the development area. 
Future acquisition strategy should consider awarding a cost 
type development contract for the militarization effort. 
Funds permitting, the award of such a contract to several 
companies would permit a "fly-off", ensuring competition for 


the production contract. 


10. As tactical digital processors become smaller due to 
advances in Large Scale Integration techniques, the need for 
non-self-hosted program development facilities becomes more 
important. Future acquisitions of tactical digital 
processors should consider award of a separate fixed-price 
contract for a program development system to support the 
Standard digital processor. Certain digital equipment 
companies specialize in design, integration, and production 
Of such specialized systems from off-the-shelf components, 
so that adequate competition should exist for such a 


procurement. 


11. The maintenance and control panels on the AN/UYK-20 
computer did not provide adequate capabilities for software 
test and debug. Future systems should include a plug-in 


software debug console to provide this capability. 
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12. A generalized real-time executive may occupy too much 
core, and require too much system overhead to be widely 
useful in a tactical system environment. Such software 
could be better optimized in designs tailored for the 
specific application. Future acguisitions should not 
include a standard real-time executive with the support 
software, but should provide some means (such as the 
Software Repository) by which projects are made aware of 


such software developed by other users. 


13. Software development engineers interviewed stated that 
source code for the various support software, including 
assemblers and compilers, was a useful tool to aid in 
debugging operational programs. Knowledge of the source 
code would allow the developer to determine the exact 
operation of the software and the philosophy behind its 
design. Future acquisition strategies should include 
outright purchase of the data rights to all software as well 


as hardware so that source code may be supplied to users. 
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APPENDIX A 


AN/UYK-7 SYSTEM DESCRIPTION 


Manufacturer 


Construction Standard 


Maximum Physical Dimensions 


Maximum Weight 


Maximum Power Consumption 


Architecture 


Main 


Word Size . 

No. of Registers | 

Inst. Execution Time 
Add/Sub/Load 
Multiply 

Divide 

Microprogrammable 

eno logy 

Privileged State 

Stack 


Memory ; 

Maximum Size 

Speed | 

Word-size . 
Memory Parity Checking 
Memory Write Protect 
Pena o nog) 

Multiported 


Instruction Set 


Double Precision 
Byte Manipulation 
Bit Manipulation 


Floating Point | 
Math/Tfrig Functions 
Negation 


Arithmetic Complement 
Stack Manipulation 


Addressing 


BeEect . 
Indirection 
Indexin 


Paging Hamedlieuee 


UNIVAC 

MIL-E-16400 
GI"Hx24"Dx20"W 
J290-tO 1, '3s9-1pDs. 
1,720 to 6,000 watts 


22D 


256K-words (16K/module) 
1.5 usec 

a2= Dts 

No 


Les ; 
Magnetic Core 
8 ports/16K module 


Yes 

Yes 

Yes 

Hardware 
Software 

One's Complement 
gae Complement 
O 


262K-words 

Multi-level 

Ui or 14 index registers 
oO 
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dae 


I/O Controller 
No. Of Channels 
Types of Channels 
Maximum Data Rate 
Processor Independent 


Maintenance/Control Panel 
Location . 
Multi-register displays 


Initial Program Load 
Reliability & Maintainability 
MTBF 


MTTR : 
Diagnostic Programs 


Modular Building Blocks 


Support Software 
Assenblers 
Compilers 
Loader 
Editor. 

Librarian |. 

Debug Routines 
Operating HEI cS 
Real-Time O 


Interrupts. 
Priority Structure 
Nesting Capability 
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rallel 
ords/sec 


or 
oN 

ro 
x 9 


Firmware 


Unknown 
15 minutes 
Firmware/Software 


Yes 


Yes 
FORTRAN/S/CMS-2 
Yes 

Yes 

yes 

Yes 

SHARE/7 

Yes 


Yes 
No 








APPENDIX B 


STANDARD MINICOMPUTER SPECIFICATIONS 


Manufacturer 

Construction Standard 
Maximum Physical Dimensions 
Maximum Weight 

Maximum Power Consumption 


Architecture 

Word Size . 

No. of Registers | 

Inst. Execution Time 
Add/Sub/Load 
Multiply 

; Divide 

Microprogrammable 

pee 01 O9Y 

Privileged State 

Stack 


Main Memory 
Maximum S1zZe 
Speed . 
Word-sizZe | 
Memory Parity Checking 
Memory Write Protect 
Mio oes 
Multiported 


Instruction Set. 
Double Precision 
Byte Manipulation 
Bit Manipulation 


Floating Point . 
Math/Trig Functions 
Negation 


Arithmetic Complement 
Stack Manipulation 


Addressing 
Direct. 
Indirection 
eer lng 
Paging Hardware 


cg 

MIL-E-16400 
Z26N"HxX ZEN Dx 19"8 
220 lbs. 

1,000 watts 


6-—-bits mininun 
expandable to 16 (general) 


1 

4 

1.2 usec 
9.0 usec 

20.0 usec 

Yes ; 

3rd generation/Mst 
Not req'd 


5K-words (8K min.) : 
-2 usec (1.0 usec ertfective) 
6~bits mininun 


RAM, non-volatile 
Two (Processor/IoOc) 


Not req'd 

Not req'd 

Not req'd 

One's and Two's Complement 
one's Or Two's Complement 
O 


65K-words 

To at least one level 
eee general registers 
es 











I/O Controller 
No. of Channels 
Types of Channels 
Maximum Data Rate 
Processor Independent 


Maintenance/Control Panel 
Location . 
Multi-register displays 


Initial Program Load 
Reliability & Maintainability 
MTBF 


MTTR . 
Diagnostic Programs 


Modular Building Blocks 


Support Software 
Assemblers © 
Compilers 
Loader 
Editor. 

Librarian . 

Debug Routines 
Operating ae 
Real-Time O 


Interrupts. 
Priority Structure 
Nesting Capability 
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16 
Sean. 
r2e -~words/sec 
e 


Optional 
Not req'd 


Hardware or Firmware 


2000 hours 
15 minutes 
Yes 


Yes 


Not req'd 
Not req'd 
Not req'd 
Not req'd 
Not req'd 
Not reg'd 
Not req'd 


Yes 
Four levels+one per group 











APPENDIX C 


GP-OU Zeno. oLEN DESCRIPTION 


Manufacturer 


Construction Standard 


Maximum Physical Dimensions 


Maximum Weight 


Maximum Power Consumption 


Architecture 


Main 


Size. 

of Registers . 

Inst. Execution Time 
Add/Sub/Load 
Multiply 

Divide 

Microprogrammable 

pee tO. Ody 

Privileged State 

Stack 


Memory 

Maximum Size 

Speed . 

Word-size . 
Memory Parity Checking 
Memory Write Protect 
eee ot Ody 

Multiported 


Word 


Instruction Set 


Double Precision 
Byte Manipulation 
Bit Manipulation 


Floating Point | 
Math/Trig Functions 
Negation 


Arithmetic Complement 
Stack Manipulation 


Addressing 


Direct. 
Indirection 
Indexin 


Paging dardwa re 


UNIVAC 
MIL-E-16400 
(2x 37 Dx3S6"W 
2,400 lbs. 
2,000 watts 


30-bits 
3 (accumulators) 


8-12 usec 

8-12 usec 

8-12 usec 

NO 

ee Components 
Oo 


No 


32K to 262K-words 
4 usec 

32=—Dit 

No 


No . 
Magnetic Core 
No 


Yes 

Yes 

No 

Software Implemented 
Software Implemented 
One's Complement 
ouers Complement 

O 


32K-words 

No 

’ Index Registers 
O 
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ee eon 


I/O Controller 
No. of Channels 
Types of Channels 
Maximum Data Rate 
Processor Independent 


Maintenance/Control Panel 
Location . : 
Multi-register displays 


Initial Program Load 
Reliability & Maintainability 
MTBF 


MITR 
Diagnostic Programs 


Modular Building Blocks 


Support Software 
Assemblers 
Compilers 
Loader 
Editor. 
Librarian | 
Debug Routines 
Operating RASS ens 
Real-Time O 


Interrupts. 
Priority Structure 
Nesting Capability 


16 
Parallel 
Unknown 
No 


Front of Cabinet 
Yes 

Firmware 

1500 hours 
Unknown 

Yes 


NO 





APPENDIX D 


AN/UYK-15(V) SYSTEM DESCRIPTION 


Manufacturer 

Construction Standard 
Maximum Physical Dimensions 
Maximum Weight 

Maximum Power Consumption 


Architecture 
Word Size . 
No. of Registers | 
Inst. Execution Time 
Add/Sub/Load 
Multiply 
) Divide 
Microprogranmmable 
ee nO] ogy 
Privileged State 
Stack - 


Main Memory 
Maximum Size 
Speed . 
Word-size |. | ; 
Memory Parity Checking 
Memory Write Protect 
irene oo) 
Multiported 


Pistruction Set. 
Double Precision 
Byte Manipulation 
Bit Manipulation 


Floating Point . 
Math/Trig Functions 
Negation 


Arithmetic Complement 
Stack Manipulation 


Addressing 
Darect . 
Indirection 
pees g 
Paging Hardware 


UNIVAC 
MIL-E-16400 
2THxI7T"Dx19"W 
200 ibs. 

500 watts 
6-bits 

4 (general) 
ah 

-8 usec 

8 

O 

ae Generation/MSI 
Oo 


‘ 
6 
0 
3 
3 
N 
T 


No 
65K-words 
0.75 usec 
18-bits 
Yes 

Yes 


Magnetic Core 
Four ports/1l6K-word bank 


Yes 
Yes 
Yes 
Software Implemented 
Hardware Implemented 
Two's and One's Complement 
ie Complement 
oO 


ca wores 


Oo 
ee General Registers 
O 





eee eae aaieie - 


I/O Controller 
No. of Channels 
Types of Channels 
Maximum Data Rate 
Processor Independent 


| Maintenance/Control Panel 
Location 


Multi-register displays 


Initial Program Load 


Reliability & Maintainability 
MTBF 


MTTR : 
Diagnostic Programs 


Modular Building Blocks 


Support Software 
Assemblers 
Compilers 
Loader 
Editor. 
Librarian . 
Debug Routines 
Operating i 
Real-Time 0 


PAcerErupts. 
Priority Structure 
Nesting Capability 


2D 


16 
Ser/Par 
190K-words/sec 
Yes 


Front of Cabinet 
No 


Firmware 


2000 hours 
15 minutes 
Firmware/Software 


Yes 


Yes 

Unknown 
Yes 

Unknown 
Unknown 
Unknown 
Unknown 
Unknown 


Yes 
Four levels-one per class 





APPENDIX E 


CP-890 SYSTEM DESCRIPTION 


Manufacturer 

Construction Standard 
Maximum PhySical Dimensions 
Maximum Weight 

Maximum Power Consumption 


Architecture 
Word Size . 
‘No. of Registers . 
Inst. Execution Time 
Add/Sub/Load 
Multiply 
; Divide 
Microprogrammable 
Pee nnoL ogy 
Privileged State 
Stack 
Main Memory 
Maximum Size 
Speed | 
Word-size . . 
Memory Parity Checking 
Memory Write Protect 
Technology 
Multiported 


Instruction Set. 
Double Precision 
Byte Manipulation 
Bit Manipulation 
Ploating Point . 
Math/Trig Functions 
Negation. 
Arithmetic Complement 
Stack Manipulation 


Addressing 
birect . 
Indirection 
Indexin 


Paging peedaeie 
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UNIVAC 
MIL-E-16400 
TA*HxXIB"Dx22"h 
700 lbs. 

1,675 watts 
30-bits 

2 (accumulators) 
8 


8 usec 
8 usec 


r 


1 
1 
N 
2 
YX 
N 


32K-words 

1.0 usec 
32-bits 

Yes 

Yes : 
Magnetic Core 
No 


Yes 

Yes 

No 

Hardware Implemented 
Software Implemented 
One's Complement 

Re = Complement 

oO 


32K-words 
Multi-level. 

i Index Registers 
O 





I/O Controller 
No. of Channels 
Types of Channels 
Maximum Data Rate 
Processor Independent 


Maintenance/Control Panel 
Location , ; 
Multi-register displays 


Initial Program Load 
Reliability & Maintainability 
MTBF 


MTTR . 
Diagnostic Programs 


Modular Building Blocks 


Support Software 
Assemblers 
Compilers 
Loader 
Editor. 

Librarian . 

Debug Routines 
Operating Pens 
Real-Time O 


Interrupts. 
Priority Structure 
Nesting Capability 


97 


16 
Parallel 
Unknown 
Yes 


Front of Cabinet 
Yes 


Software 


2000 hours 
30 minutes 
Firmnware/Software 


Yes 


Yes 

Unknown 
Yes 

Unknown 
Unknown 
Unknown 
Unknown 
Unknown 


Yes 
Four-one per class 














APPENDIX F 


AN/UYK-12(V) SYSTEM DESCRIPTION 


Manufacturer 

Construction Standard 
Maximum Physical Dimensions 
Maximum Weight 

Maximum Power Consumption 


Architecture 

Word Size . 

No. of Registers . 

Inst. Execution Time 
Add/Sub/Load 
Multiply 

Divide 

Microprogrammable 

Mee ROL Ody 

Privileged State 

Stack 


Memory 

Maximum Size 

Speed | 

Word-size . i 
Memory Parity Checking 
Memory Write Protect 
Beano + OSY 

Multiported 


Main 


Instruction Set. 
Double Precision 
Byte Manipulation 
Bit Manipulation 


Floating Point . 
Math/Trig Functions 
Negation 


Arithmetic Complement 
Stack Manipulation 


Addressing 
Direct. 
Indirection 
Indexin 


Paging Hee eee 


Rolm Corporation 
MIL-E-5400 
7eOUHXIO. M!DxiIZ. SHH 
60 lbs. 

275 watts 


6-bits 
(accumulators) 


9 usec 
7 usec 
7 usec 


O 
rd Generation/MSI 
oO 
oO 


K expandable to 32K 
-O0 usec 


N 
Magnetic Core 
No 


Yes 

Yes 

Yes 

Software Implemented 
Software Implemented 
One's Complement 
ee Complement 

oO 


1,924 words 
Multi-level 

Two accumulators 
Yes 


98 





I/O Controiler 
No. of Channels 
Types of Channels 
Maximum Data Rate 
Processor Independent 


Maintenance/Control Panel 
Location |. : 
Multi-register displays 


Initial Program Load 
Reliability & Maintainability 
MTBF 


MTTR 
Diagnostic Programs 
Modular Building Blocks 


Support Software 
Assemblers 
Compilers 
Loader 
Editor. 
Librarian . 
Debug Routines 
Operating a a 
Real-Time O 


Interrupts. 
Priority Structure 
Nesting Capability 
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poueos= on I/O bus 
c/Par 

OK 

S 


6 1 
Se 
600K-words/sec 
Ye 


Attached or Remote 
No 


Firmware 


00 hours 


0 
minutes 


For memory & I/0 


yes 
ea eR SEC ALGOE 
es 


Yes 
Yes 


Yes ; 
Batch/Disk 
Disk 


Yes 
Yes 








APPENDIX G 


DESCRIPTION OF SYSTEM SOFTWARE 


Level 0 Qperating Systea 


* Equipment Configuration 
es UNIVAC 1108 hosted 


* System Routines 
es AN/UYK-20 Simulator 
s Macro-Assenbler 
es System Generator 
s FORTRAN Cross-Compiler 
es CMS-2M Cross-Compiler 


a Transfer Utilities 


* Written in FORTRAN IV except for the macro-assembler 


which is written in UNIVAC 1108 assembly language. 


evel I Qperating Systea 


= = — a= > oe ae a a = = 


* Equipment Configuration 

es AN/OYK-20(¥V) hosted (a minimum of 24K-words of 
memory required) 

s Paper Tape Reader/Punch (required) 

es Keyboard/Printer (required) 

s Up to four Magnetic Tape Units (optional) 

»s Line Printer (optional) 


»s Card Reader/Punch (optional) 


* System Routines 
s Core-Resident Routines (interactive systen 


ccntroller, I/O controller) 
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Text Editor (edits source code) 

Linking-Loader Subsystem {loads relocatable 
object code into memory) 

Debug Utility System (memory inspect and change, 
absolute core dump or load, absolute correction 
load, snapshot dump, memory search and constant 
storage) 

System Tape Generator 

Basic Assembler (generates relocatable object 


code - no macro capability) 


* Written in FORTRAN IV 


Level II Qperating Systea 


* Eguipment Configuration 


AN/UYK-20(V) hosted (minimum 65K-words of core 
memory required) 

Keyboard/Printer (required) 

Card Reader/Punch (required) 


Four Magnetic Tape Units (required) 


* System Routines 


Core-Resident Routines (system controlier, I/0 
ccntroller, batch monitor) 

ULTRA-16 Macro-Assembler (generates relocatable 
object code) 

CMS-2M Compiler 

FORTRAN IV Compiler 

Linking Loader (loads relocatable object code) 
Debug Utilities (memory inspect and change, 
memory dump, absolute core dump or load, absolute 
correction load, snap-shot dump, memory search, 
and constant storage) 

Conversion Subroutines (ASCII decimal integer to 
binary integer and vv., ASCII characters to field 


data characters and vv., ASCII octal to binary 
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CMS-28 


integer and vv.) 

es General Utilities (transfer data from one 
peripheral device to another) 

s Librarian (edit. and update user source code, 
object code and absolute code) 

e System Tape Generator 


ws Disk File Manager 


Compiler 


CMS-2M language 1S a subset of CMS-2, the standard 
Navy high-level language for tactical applications. 


Produces relocatable object code for the AN/UYK~-20 


computer. 


Equipment Configuration 
» Host Computer 
e Card Reader/Punch 
se Line Printer 


»s Four Magnetic Tape Units 


Host Computers 
ws AN/UYK-20(V) with Level II Operating System 
e UNIVAC 1108 
e IBM 360/370 
» CDC 6600/6700 


Incorporates capabilities for both Scientific 


calculation and data management. 


Uses familiar English words and algebraic expressions 
to define and describe logical operations and data 


Manipulations. 


Components 
a Lexical Analyser - prepares source code input for 
translation 


»e Syntax Analyser - translates source code into 


OZ 








oe 


ood oe 
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intermediate language and generates error 
messages. 

e Direct Code Processor - translates direct code 
into intermediate language 

» Code Generator - translates intermediate language 
code into relocatable object code 


e Output Editor - produces hardcopy listings 


Machine Independent System Generator 





* Produces system tapes for AN/UYK-20(V) from object 


files produced on host machines 


* Host Machines 
e UNIVAC 1108 
e CDC 6600/6700 


* Peripheral suite as specified by the user 


* Building block modules provide basic computer program 
management functions upon which the user builds his 
Operational programs 

es Initialization Routines 

»s Scheduling Routines 

»e Interrupt Management Routines 
» I/O Management Routines 


s Error Management Routines 


CMS-2Y¥ (20) Compiler 
* AN/UYK-7 Computer with SHARE/7 Operating Systen 


* Components 
» UYK-20 Code Generator 
e ULTRA/16 Assembler 
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a UYK-7 hosted Loader 
a UYK-20 Simulator/Debug Tool 


* Features 
e Interfaces with CMS-2Y(7) Librarian for source 
code editing 
a Extensive Optimization 
a Produces side-by-side source code/object code 


listings 
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APPENDIX H 


AN/UYK-20 (V) 


Manufacturer 

Construction Standard 
Maximum Physical Dimensions 
Maximum Weight 

Maximum Power Consumption 


Architecture 

Word Size . 

No. of Registers . 

Inst. Execution Time 
Add/Sub/Load 
Multiply 

Divide 

Microprogrammable 

nO Tt OSY 

Privileged State 

Stack 


Main Memory ; 
Maximum S1ze 
Speed . 
Word-size | 
Memory Parity Checking 
Memory Write Protect 
Technology 
Multiported 


Instruction Set. 
Double Precision 
Byte Manipulation 
Bit Manipulation 


Floating Point . 
Math/Trig Functions 
Negation 


Arithmetic Complement 
Stack Manipulation 


Addressing 
Direct | 
Indirection 
pueexing 
Paging Hardware 


DPS DESCRIPTION 


UNIVAC 
MIL-E-16400 
lea6"Hx24.O0"Dx17.5" Nh 


185 lbs. 

900 watts 

16-bits 

16 or 32 (general) 
0.75 usec 

3.8 usec 

6.8 usec 

Yes (512 word growth) 
ee generation/MSI 
O 

No 

65K-words 
0.75 usec effective 
16-bits 

No 

No . 

Magnetic Core RAM 
Iwo (CP/IOC and DMA) 


Yes 
Load/Index/Store/Com pare 
Linited 

Yes 

Yes 

One's and Two's Complement 
ee Complement 

O 


K-words 
lti-level ; 
l general registers 


6 
A 
64 page address registers 


5 
u 
di 
4 
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a rr har ae 


I/O Controller 
No. of Channels 
Types of Channels 
Maximum Data Rate 
Processor Independent 


Maintenance/Control Panel 
Location . 
Multi-register displays 


Initial Program Load 
Reliability & Maintainability 
MTBF 


MTTR ; 
Diagnostic Programs 


Modular Building Blocks 


Support Software 
Assemblers 
Compilers 
Loader 
Editor. 

Librarian | 

Debug Routines 
Operating A 
Real-Time O 


ficerrupts 
Pricrity Structure 
Nesting Capability 


16 full duplex 
Serlal/Parallel/DMA 
vee wee per sec 
es 


Inside front cover 
No 


192-word Read-Only-Memory 


1500 demonstrated. 
15 minutes specified 
Pirmware/Software 


Yes 


tae RO=20 


ULTRA/16, 
GHS =2M 


FORTRAN, 
Yes 

Yes 

Yes 

Yes 
Levels 0, 1,,21 
SDEX-20 


Yes-three classes 
Limited-one per class 
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APPENDIX 1 


BASIC AN/UYK-20 HARDWARE CONFIGURATION AND OPTIONS 


Configuration 
Microprogrammed Processor 
InputyOutput Controller 
16 General Registers 


Bootstrap ROM - two programs for channels and 


peripheral devices selected by the uSer 
8K-words of Core Memory 


Power Supply as specified by the user; 
»s Single phase, 115 volts, 60 or 400 hertz 
*s Three phase delta, 115 volts, 60 or 400 hertz 
»s Three phase wye, 208 volts, 60 or 400 hertz 


Four Input/Output Channels (one group) as specified 
by the user: 
e MIL-STD-188C Synchronous (0 to 9600 baud) 
a MIL-STD-188C Asynchronous (four rates of 75, 150, 
300, 600, 1200, or 2400 baud) 
® RS-232C Synchronous (0 to 9600 baud) 
a RS-232C Asynchronous (four rates of 75, 150, 300, 
600, 1200, or 2400 baud) 
es NTDS Slow, Fast, and ANEW in a normal or 


intercomputer mode 


Options Available 


* 8K-word Memory Modules (up to 65K-words) 
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Additional 16 Gen2ral Registers 


Direct Memory Access (DMA) capability 


MATHPAC Modules 

Microgrowth Card 

Special Tools Kit 

Spare Parts Kit (one year supply) 
Different Bootstrap Cards 


Up to 16 I/0 channels in four 
options as specified above plus: 

« NIDS Serial (32-bit) 

ea Dual Channel NTDS (32-bit) 


Engineering Services 


Training Courses 
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APPENDIX J 


ROLM 1602 SYSTEM DESCRIPTION 


Manufacturer 

Construction Standard 
Maximum Physical Dimensions 
Maximum Weight 

Maximum Power Consumption 


Architecture 

Word Size | 

No. of Registers . 

Inst. Execution T1me 
Add/Sub/Load 
Bultap ly 

Divide 

Microprogrammable 

ee n02 Coy 

Privileged State 

Stack 


Main Memory 
Maximum Size 
Speed . 
Word-size . 
Memory Parity Checking 
Memory Write Protect 
Technology 
Multiported 


Destruction Set. 
Double Precision 
Byte Manipulation 
Bit Manipulation 


Floating Point . 
Math/Trig Functions 
Negation 


Arithmetic Complement 
Stack Manipulation 


Addressing 
Parect  . 
Indirection 
mee xing 
Paging Hardware 


Rolm Corporation 
MIL-E-5400/16400 
Tao*Hx 10. 1"Dx12.5"W 
100 lbs. 

350 watts 


6-bits 
(accumulators) 


-Q0 usec 
-3 usec 
~-4 usec 
es (3.5K-words aeo eee 
rd generation/MSI/LSI 


65K-words 

1.0 usec 

16-bits 

NO 

NO ; 

Core or Semiconductor 
Two (CP/DMA) 


Yes 

No 

Yes 

Yes 

Firmware 

Two's Complement 
Tee Complement 
es: 


1,024 words 
Multi-level 

Two accumulators 
Yes 
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I/O Controller 
No. of Channels 
Types of Channels 
Maximum Data Rate 
Processor Independent 


Maintenance/Control Panel 
Location . . 
Multi-register displays 


Initial Program Load 
Reliability & Maintainability 
MTBF 


MTTR ; 
Diagnostic Programs 


Modular Building Blocks 


Support Software 
Assemblers 
Compilers 
Loader 
Editor. 

Librarian | 

Debug Routines 
Operating SL OLeNS 
Real-Time O 


Interrupts, 
Priority Structure 
Nesting Capability 


devices on I/0 bus 
lal/Parallel 
0OK-words/sec 

only 


acne’ Or Remote 
Oo 


Firmware 


11,000 hours 
28.6 minutes 
Firmware/Software 


Yes 


Self-hosted and cross- 
BASIC/ALGOL/ FORTRAN 
Yes 

Yes 

Yes 

Yes 
Disk-based 
Yes 


Yes 
Yes 
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APPENDIX K 


HP2100A SYSTEM DESCRIPTION 


Manufacturer 

Construction Standard 
Maximum Physical Dimensions 
Maximum Weight 

Maximum Power Consumption 


Architecture 

Word Size | 

No. of Registers . 

Inst. Execution Time 
Add/Sub/Load 
Multiply 

Divide 

Microprogrammable 

pee PO. O9Y 

Privileged State 

Stack 


Main Memory 
Maximum Size 
Speed . 
Word-size . . 
Memory Parity Checking 
Memory Write Protect 
= OS EEE 
Multiported 


iustruction Set. 
Double Precision 
Byte Manipulation 
Bit Manipulation 


Ploating Point . 
Math/Trig Functions 
Negation 


Arithmetic Complement 
Stack Manipulation 


Addressing 
Direct. 
Indirection 
eee 
Paging Hardware 


Hewlett Packard 
Commercial 

ies axezo. OV DxX16 63" 
111 lbs. 

800 watts 

16-bits 

Two (accumulators) 


96 usec 
7 usec 


7 usec 
Writable Control Store) 


s ( 
L/ LS 


2 ed 
00ND AO: 


32K-words 
0.98 usec 
17-bit 

Yes 

Yes 

pores Planar 


Core 
hree (CP/DMA-1/DMA- 2) 


Load/Store only 
No 


Yes 

Yes 

No 

One's and Two's Complement 
ro Complement 

oO 


048 words 
lti-level 








I/o Controller 
No. of Channels 
Types of Channels 
Maximum Data Rate 
Processor Independent 


Maintenance/Control Panel 
Location . : 
Multi-register displays 


Initial Program Load 
Reliability & Maintainability 
MTBF 


MTTR ; 
Diagnostic Programs 


Modular Building Blocks 


Support Software 
Assemblers 
Compilers 
Loader 
Editor. 

Librarian . 

Debug Routines 
Operating Sevens 
Real-Time O 


Interrupts, 
Priority Structure 
Nesting Capability 


14 
Serial/Parallel 
1,000K-words/sec 
DAA only 


Front of chassis 
No 


Pirmware 


Unknown 
Unknown 
Software 


Yes 


Yes 
FORTRAN/ALGOL/BASIC 
Yes 


Yes 
Yes 
Yes 
Yes 
Yes 


None 
None 








APPENDIX L 


DEC PDP-11/45 SYSTEM DESCRIPTION 


Manufacturer 

Construction Standard 
Maximum Physical Dimensions 
Maximum Weight 

Maximum Power Consumption 


Architecture 

Borda Size | 

NO. of Registers | 

inst. Execution Tine 
Add/Sub/Load 
Multiply 

Divide 

Microprcgrammable 

pee 201 OGY 

Privileged State 

Seack 


Main Memory 
Maximum Size 
Speed . 
Word-size . : 
Memory Parity Checking 
Memory Write Protect 
Technology 
Multiported 


Instruction Set. 
Double Precision 
Byte Manipulation 
Bit Manipulation 


mrOating Point . 
Math/Trig Functions 
Negation 


Arithmetic Complement 
Stack Manipulation 


Addressing 
Direct. 
Indirection 
eg sed 
Paging Hardware 


Digital Equipment Corporation 
Commercial 

7 Ved" Axed. O"DE21. 7" 

300 lbs. 

2,300 watts 


it (18-bit addresses) 
general) 


~~ 


Vee: 
- Kernal & Supervisor 


128K-words 

Uz ton 0. J6 Busce 

Tome ae (18-bit for parity) 
es 


Yes 
Core/MOS/Bipolar 
Single - UNIBUS structure 


Yes 
Yes 
Yes 
Yes 
Software 
One's or Two's Complement 
aos Complement 
es 


Go Kee y tes 


es 
All general registers 
Yes 











I/O Contrceller 
No. of Channels 
Types of Channels 
Maximum Data Rate 
Processor Independent 


Maintenance/Control Panel 
Location . . 
Multi-register displays 


Initial Program Load 
Reliability & Maintainability 
MTBF 


MTTR ; 
Diagnostic Programs 


Modular Building Blocks 


Support Software 
Assemblers 
Conpilers 
Loader 
Editor. 
Librarian . 
Debug Routines 
Operating Oe Noon 
Real-Time O 


interrupts. 
Priority Structure 
Nesting Capability 


Multiplexed UNIBUS 

Serial/Parallel 

Aged ESN ae 
es 


Front of chassis 
Yes 


Software 


OGnknown 
Unknown 
Software 


Yes 


Yes 
BASIC/FORTRAN/C 
Yes 
Yes 
Yes 
Yes 
Yes 
Yes 


Yes 
yes 





APPENDIX & 


VARIAN-73 SYSTEM DESCRIPTION 


Manufacturer 

Construction Standard 
Maximum Physical Dimensions 
Maximum Weight 

Maximum Power Consumption 


Architecture 

Nora Size . 

No. of Registers . 

Inst. Execution Time 
AddySub/Load 
Multiply 

Divide 

Microprogrammable 

pee anol ogy 

Privileged State 

Stack 


Main Memory 
Maximum Size 
Speed . 
WOrd-size . : 
Memory Parity Checking 
Memory Write Protect 
Technology 
Multiported 


Eastruction Set. 
Double Precision 
Byte Manipulation 
Bit Manipulation 
Floating Point . 
Math/Trig Functions 
Negation. 
Arithmetic Complement 
Stack Manipulation 


Addressing 
Direct. 
Indirection 
peacxand 
Paging Hardware 


Varian Data Machines 
Commercial 
14"Hx20.5"Dx19"W 

120 lbs. 

900 watts 

-bit 
(general) 

5 usec (MOS 


HO 


usec (MOS 
usec (MOS 
eee Control Store) 


AAs neO —a— 


262K-words 

-33 usec (MOS) /.66 usec(Core) 
G=piu 

Yes 

Yes 

MOS/Core 

Two (CP/DMA) 


Software 
Software 
Onets or Two's Complement 
aos Complement 
O 


2K~-words 
Multi-Level 
Yes 

Yes 
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Oo. Of Channels 
Types of Channels 
Maximum Data Rate 
Processor Independent 


I/o et 2+ er 


Maintenance/Control Panel 
Location . 
Multi-register displays 


Initial Program Load 
Reliability & Maintainability 
BOBF 


MTTR 
Diagnostic Programs 


Modular Building Blocks 


Support Software 
Assemblers 
Compilers 
Loader 
Editor 
Librarian 
Debug Routines 
Operating aneters 
Real-Tine 


Interrupts. 
Priority Structure 
Nesting Capability 


Seriai/parall eal Bus 
Serial/Paral 

FORO CaERE cee 
aha only 


Front of chassis 
No 


Firmware 


Unknown 
Onknown 
Software 


Yes 


Yes 
BASIC /FORTRAN/SRPG 
Yes 
Yes 
Yes 
Yes 
Yes 
Yes 


Yes 
No 
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San Diego, California 92147 
ATTN: LCDR J. Roudebush 

Mr. V. Khosharian 


Commanding Officer 

Naval Electronic Systems Engineering Center 
P.O. Box 80337 

4297 Pacific Highway 

San Diego, California 92138 

ATTN: Mr. C. Benson 
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